Skip to main content
The reference glossary for Forge’s core abstractions. Each concept is explained in context — what it is, where it lives, and how it connects to the rest of the platform.

​
⚙️ Workflow Concepts

The workflow definition language. A validated by Zod schemas. A .lobsterX document declares steps, dependencies, phases, roles, policies, timeouts, and failure handlers. It is declarative and versionable — the definition describes what should happen, not how the runtime executes it. The Convex interpreter parses .lobsterX into a DAG for execution.
Step IDs use snake_case. Workflow names use kebab-case.
The execution graph resolved from a .lobsterX definition. Each step is a node; depends_on declarations form directed edges. The interpreter walks the DAG to determine which steps are ready to run, respecting dependency order and parallelism opportunities. Cycles are rejected at validation time.
The atomic unit of work in a workflow. Each step has an id, command, role, optional depends_on, inputs, outputs, timeout, and on_failure handler. Steps are dispatched individually through the . A step can execute on a gateway (via Bridge) or inside Convex (via a native agent).
A visual and organizational grouping of steps within a .lobsterX definition. Phases do not affect execution order — that is determined solely by the DAG. Phases exist for human readability in the dashboard and for structuring approval checkpoints.
The mechanism that connects abstract roles declared in .lobsterX steps to concrete . A step declares role: reviewer; a role binding maps reviewer to a specific agent definition and gateway configuration. This indirection lets the same workflow run with different agent assignments.
A snapshot of workflow execution state at a specific point. Checkpoints enable (rolling back to an earlier state) and (forking execution from a prior state). Stored durably in Convex alongside the workflow run record.

​
🤖 Agent Concepts

The declarative specification of an agent’s identity and capabilities. Stored in the Convex agent registry. Includes the agent’s name, model configuration, tool profiles, workspace files (SOUL.md, IDENTITY.md), tier classification, and sandbox settings. An agent definition is a template — it describes what an agent is.
A running instance of an agent definition, bound to a specific . The deployment is the live, addressable entity that receives work. Multiple deployments can share the same definition with different gateway configurations or model overrides.
A pre-built, reusable agent configuration in the template gallery. Templates provide one-click deployment of common agent patterns (code reviewer, technical writer, research analyst). They bundle a definition, recommended skills, and default model configuration.
A packaged instruction set that teaches an agent how to perform a specific task domain. Skills contain a SKILL.md file with conventions, context, and examples. They are registered in the Convex skill registry and can be attached to agent definitions. Skills are the “training manuals” in the agent capability model.
A runtime primitive that agents invoke to interact with external systems. Tools are the lowest layer of the agent capability model — the actual functions an agent can call (file operations, API calls, shell commands, code execution). Registered in Convex and scoped by agent sandbox settings.
A bounded interaction context between an operator (or system) and an agent deployment. Sessions have a lifecycle (created, active, completed, failed), maintain conversation state, and produce observable traces. Sessions are the unit of agent execution billing.
The agent memory model operates across three layers:
  • Session memory — working context within a single session
  • Channel memory — institutional knowledge shared across sessions within a
  • Long-term memory — RAG-indexed durable archive for cross-channel recall
Each layer has different persistence, scope, and retrieval characteristics. See the Agent Memory PRD for the full model.

​
🛡️ Governance Concepts

A pre-dispatch check in the governance pipeline. Forge runs 10 safety gates before any step executes: gateway health, agent availability, concurrency limits, rate limits, agent budget, envelope budgets, trust level, context trust, policy evaluation, and approval status. Each gate returns allow, block, or hold. A single block stops execution.
The structured output of the governance pipeline. Contains a (allow, block, or hold), the gate that produced it, scope constraints, and audit metadata. Every dispatch decision is recorded for the audit trail. The hold disposition triggers the approval workflow.
A declarative governance rule evaluated during the safety gate pipeline. Policies define conditions under which steps require approval, enforce budget thresholds, restrict model usage, or impose operational constraints. Policies are scoped to organizations, teams, or specific workflow definitions.
A checkpoint triggered when a governance decision returns hold. An approval request is created, routed to the appropriate reviewer (determined by policy and role resolution), and the step remains paused until approved or rejected. Approvals have configurable escalation and timeout rules. See Approval Lifecycle.
A spending constraint applied at multiple levels of the organizational hierarchy: company, department, team, project, and individual workflow. The budget gate checks remaining allocation before dispatching any step that incurs token cost. Dual aggregation tracks spend along both the task chain and the .

​
🏗️ Infrastructure Concepts

An autonomous production unit. A Factory combines a Factory Type, a agent, a team of worker agents, communication channels, cloud dev environments, and a budget. Factories are the organizational unit for sustained, multi-agent project work.
A communication context in the Hybrid Workforce Chat system. Channels are scoped by type: factory, project, team, direct, or personal. Each channel contains sessions (finite conversations) and messages. Multi-agent channels use to control which agents participate in which messages.
A runtime-specific implementation of the ExecutionAdapter interface. Each gateway has a corresponding adapter in the Bridge layer. Adapters translate the platform’s dispatch protocol into gateway-native API calls. Current adapters: OpenClaw, Claude Agent SDK, Vercel AI, and Gloo AI. Gloo AI adds unique capabilities: auto-routing (automatic model tier selection per request), grounded completions (RAG-powered responses with source attribution), and tradition (values-aligned theological perspective). Both grounded completions and tradition are opt-in per gateway.
A pluggable execution runtime that runs agent work. Gateways manage sessions, tool invocations, model calls, and channel integrations. They are external to Forge — the platform connects to them through Bridge adapters. The gateway interface is designed for extensibility; new runtimes are added by implementing .
The shared abstraction for any entity that performs work. Workers can be EMPLOYEE, CONTRACTOR, or AGENT type. The organizational hierarchy flows Company → Departments → Teams → Positions → Workers. This unified model allows humans and agents to coexist in the same governance, budgeting, and attribution systems.
The system that attributes every token spend to a worker and a task. Dual aggregation chains track cost along two dimensions: the task chain (Token → Task → Workflow → Project → Objective) and the worker chain (Token → Worker → Team → Department → Company). This enables cost analysis at any level of either hierarchy.