Skip to main content
Convex is the orchestration brain of Gloo Forge. It owns all durable state, runs the workflow interpreter, enforces governance decisions, and hosts the platformโ€™s native agents. Nothing happens in Forge that Convex does not know about.

ConvexWhy Convex

Three properties make Convex the right foundation for an agentic orchestration platform:
PropertyWhat it means for Forge
Transactional mutationsGovernance gate checks and step state transitions execute atomically. A step cannot be marked โ€œrunningโ€ unless the concurrency limit passes in the same transaction.
Reactive subscriptionsDashboard state updates in real time without polling. When a step completes or an approval resolves, every connected Burgundy client sees it instantly.
Durable workflowsThe runs as a @convex-dev/workflow instance. If the Convex process restarts, the interpreter resumes from its last event checkpoint.

ConvexConvex Execution Model

Convex Execution Model

๐Ÿ“– Queriesยท Read-only, reactive, cached

Dashboard subscribes to query results. Convex pushes updates when underlying data changes. Zero polling.

โœ๏ธ Mutationsยท Transactional, serializable

State changes execute atomically. Governance checks, step transitions, and budget deductions are mutations.

๐Ÿ”— Actionsยท Side effects, external calls

HTTP dispatch to Bridge, LLM calls for native agents, gateway health checks. Can call mutations for state.

๐Ÿ”„ Durable Workflowsยท @convex-dev/workflow

The .lobsterX interpreter runs as a durable workflow. Event-driven dispatch with checkpoint recovery.

๐Ÿ” Ownership Boundary

Ownership Boundary

ConvexConvex Owns
Workflow DefinitionsDAG ResolutionGovernance DecisionsBudget EnforcementRun History + AuditAgent Registry
๐Ÿ”Œ Gateway Owns
Live LLM ExecutionSession StateRuntime EnvironmentAgent WorkspaceCost Reporting

๐Ÿ“‹ Ownership Table

DomainConvex ownsGateway owns
Workflow definitions.lobsterX YAML, workflow versions, deployment configsโ€”
Run orchestrationDAG resolution, step dispatch, condition evaluation, failure policiesLive LLM execution
Governance10-gate pipeline, policy evaluation, approval lifecycleโ€”
Agent registryDefinitions, deployments, trust levels, skill assignments, role bindingsRuntime agent configs (OpenClaw only)
Budget and costBudget envelopes, spend tracking, cost aggregation, monthly resetsPer-execution token count and cost
Audit trailGovernance decisions, step events, approval resolutions, cost eventsโ€”
Chat and memoryChannels, sessions, messages, session/channel/long-term memoryโ€”
FactoriesFactory definitions, team assignments, blueprints, dev environmentsCode execution (via exe.dev)

๐Ÿ—‚๏ธ Schema Organization

The 117-table schema is split across individual files in convex/schema/ and assembled by convex/schema.ts. Tables are grouped by domain:
TablePurpose
workflowsWorkflow metadata (name, description, creator)
workflowDocumentsPinned .lobsterX YAML definitions
workflowVersionsVersion history for workflow definitions
workflowRunsActive and historical run state
workflowCheckpointsInterpreter checkpoint snapshots for rewind/branch
stepResultsPer-step execution results, outputs, cost
executionEventsGranular execution events (tool calls, progress)
approvalsHITL approval records (pending/approved/rejected)
deploymentsWorkflow-to-gateway deployment bindings

โš™๏ธ The Workflow Interpreter

The interpreter (convex/interpreter.ts, 2200+ lines) is the core of Forgeโ€™s execution engine. It runs as a Convex durable workflow and implements a deterministic event loop:
  1. Parse the pinned .lobsterX YAML
  2. Resolve the DAG into execution layers (groups of parallelizable steps)
  3. Dispatch ready steps through the governance pipeline
  4. Wait for completion events (callbacks from Bridge)
  5. Advance the DAG, evaluate conditions, handle failures
  6. Repeat until all steps are resolved or the run fails
The interpreter itself consumes zero LLM tokens. It is purely deterministic orchestration. All LLM execution happens in gateways.

ConvexConvex-Native Agents

Forge runs four agent types directly inside Convex using @convex-dev/agents. These agents have persistent threads, tool access, and transactional state management.
AgentRoleKey capabilities
Factory ManagerOverseer of a Factoryโ€™s hybrid workforceTask creation, worker coordination, budget management, GitHub integration
Factory WorkerFills positions in Factory teamsCode execution via exe.dev, skill-based task completion
Task ManagerProject task orchestrationTask decomposition, dependency tracking, sprint management
Copilot AnalysisRun analysis and diagnosticsPost-run analysis, error investigation, performance insights
Convex-native agents do not go through Bridge or the governance gate pipeline. They execute within Convexโ€™s transactional boundary, call tools defined as Convex functions, and persist their conversation threads directly in the Convex agents component.

๐Ÿ• Scheduled Operations

Convex runs 25+ cron jobs for platform maintenance:
CategoryJobsFrequency
Gateway healthHealth check all gatewaysEvery 60 seconds
Execution hardeningWorkflow watchdog, step timeout enforcerEvery 2 min / 60 sec
ApprovalsReminder escalation, auto-reject staleEvery 15 min / daily
Cost analyticsHourly rollup, daily rollup, weekly compactionHourly / daily / weekly
Budget managementDaily/weekly/monthly envelope resetsOn schedule
Data retentionToken events (90d), audit events (365d), callback dedup (24h)Daily / hourly
Agent syncRegistry sync for Convex-native and SDK agentsDaily
Memory compactionSession memory compaction, channel-to-LTM promotionEvery 6h / weekly

๐Ÿ”’ Function Model

Convex functions follow a strict access control pattern:
// Public query -- requires authentication
export const list = query({
  handler: async (ctx) => {
    await requireAuth(ctx);
    // ...
  },
});

// Public mutation -- requires specific permission
export const resolve = mutation({
  handler: async (ctx, args) => {
    await requirePermission(ctx, "governance:approve");
    // ...
  },
});
Every public mutation must use requirePermission(ctx, "scope:action"), not just requireAuth. The latter only checks identity; the former checks authorization against the RBAC system.
See also: System Overview | Data Model | Workflow Execution Flow