Architecture

Redgold brings application authoring and operation into one managed platform. Describe the behavior you need, review the proposed application change, and use the deployed result. Redgold operates the routing, execution, typed storage, builds, and deployment behind it. Persistent agents help create and maintain the application; issues and workstreams keep that work connected to an outcome.

Fully managed describes who operates the infrastructure. Pipeline applications are currently a managed preview: account setup, datasets, application publication, and environment provisioning are coordinated during onboarding.

Two connected paths

An application has a delivery path that changes its behavior and a request path that serves its users. An agent finishing a task changes neither the live route nor the stored data by itself; the reviewed change must pass through publication and deployment.

flowchart TB
  Goal[Application objective] --> Work[Workstream and issues]
  Work --> Agent[Managed agent workspace]
  Agent --> Git[Reviewed schemas, pipelines, transforms and tests]
  Git --> Release[Managed build and publication]
  Release --> Runtime[Deployed application revision]
  User[App user or API client] --> Edge[Authenticated edge]
  Edge --> Executor[Pipeline executor]
  Runtime --> Executor
  Executor --> Data[Data engine and typed storage]
  Executor --> Integration[Authorized external services]

The application contract

The durable application definition lives in Git. Rust serde schemas describe records; pipeline TOML describes routes and execution stages; transforms supply domain behavior; tests and example requests define the expected result. Managed publication validates these artifacts together and deploys the supported runtime configuration. The support-triage walkthrough shows this contract in code.

Read the architecture through an event

• A request through the platform follows a support request from authentication to a stored queue record, including failure points.
• Agent work and durable state follows an application change through issues, execution, review and recovery.
• Managed deployment explains how approved source becomes a live revision and what counts as verification.
• Running agent work explains the customer workflow for issues, workstreams, fleet supervision and lifecycle decisions.

Why these boundaries exist

The edge authenticates and relays requests; application code runs in executors. This keeps route handling separate from the compute that can fail or need more capacity. The data engine owns durable writes and scoped reads, so an application uses the managed data boundary instead of operating a separate storage stack. Git records intended application changes; runtime evidence tells you what is actually serving. Keeping both is essential when a build passes but a rollout has not reached the expected revision.

Shared infrastructure also means applications follow explicit schema, capability, and publication contracts. A new external dependency or runtime requirement may need onboarding work. The runtime placement guide describes which execution choices are available and which remain previews.

External systems fit around the managed application

A managed pipeline application can integrate with authorized external services and data sources. Agents can also work on an external repository whose CI and hosting stay elsewhere. The model API can be used independently by existing applications. These connections do not automatically move external deployment, storage, or access policy under Redgold management.

See GitHub repository automation, and the model API for their supported boundaries.

Current capability matrix

Status verified 2026-08-14 against the executor conformance test and the Git-authored route inventory.