Forge Platform

Handbook

Agent Workcells as Replaceable Bounded Runtimes

Forge's workcell model turns agents into bounded, replaceable runtime components rather than platform owners. A workcell accepts a WorkcellRequest, performs scoped work under an approval mode, and returns a…

Updated

Core Thesis

Forge's workcell model turns agents into bounded, replaceable runtime components rather than platform owners. A workcell accepts a WorkcellRequest, performs scoped work under an approval mode, and returns a WorkcellResult linked to a ForgeRun.

The standout thought is: agents should be powerful enough to work, but not powerful enough to become the authority.

Condensed Thought

The workcell abstraction lets Forge plug in many kinds of agents and tools: adaptive operators, implementation workers, reviewers, channel gateways, Versona runners, evidence summarizers, local runners, Cursor CLI steps, local LLM workers, and future systems that do not exist yet.

That makes the Forge ecosystem resilient. When a new coding agent becomes better than the current one, Forge should not need to rebuild its governance architecture. It should adapt the new tool into the WorkcellRequest and WorkcellResult contract.

Why It Stands Out

Many agentic SDLC products make the agent the center of the experience and the center of operational state. Forge flips that. The workcell does useful work, but Lenses, ForgeRun, ApprovalRequest, EvidencePacket, Blueprints, LCDL, and Fleet define the operating envelope.

This is a strong anti-lock-in pattern. It gives Forge a vendor-neutral posture while still allowing deep integrations with high-value agents. It also encourages safer autonomy because a workcell can be constrained by approval mode, scope, templates, evidence expectations, and review gates.

Forge Ecosystem Hooks

  • WorkcellRequest defines the requested scoped work.
  • WorkcellResult returns the outcome for review.
  • ForgeRun anchors the work to the run spine.
  • Approval modes define what the workcell may do.
  • Fleet can execute workcell workloads inside controlled containers.
  • LCDL can verify or reason over workcell output.
  • Lenses reviews the result and keeps the system of record.

Potential workcell types include operator, implementation worker, reviewer, channel gateway, Versona runner, and evidence summarizer.

Architecture Implications

A strong workcell architecture needs:

  1. A stable request and result schema.
  2. Explicit declaration of approval mode and allowed actions.
  3. Run correlation through ForgeRun and AgentRun identifiers.
  4. Clear ownership boundaries: workcells do not write final state directly.
  5. Standard output expectations for evidence, logs, diffs, findings, and confidence.
  6. A workcell catalog that describes capabilities and limits.
  7. A failure taxonomy that distinguishes agent failure, policy failure, execution failure, and insufficient evidence.

The goal is not to make every workcell identical. The goal is to make every workcell governable.

Blog Post Seed Paragraph

The agent landscape changes quickly. A tool that looks dominant today may be replaced by a better local model, a better cloud coding agent, a better CLI agent, or a better workflow runner tomorrow. Forge avoids building the platform around any one agent by treating agents as workcells. A workcell is bounded: it receives a request, operates under a declared approval mode, and returns a reviewable result linked to a ForgeRun. The agent can be swapped. The governance remains.

Risks And Counterarguments

The workcell abstraction can become too generic if it tries to hide all differences between tools. Forge should preserve tool-specific strengths while standardizing governance-critical fields. The contract should be strict about accountability and flexible about implementation.

Who this is for

Architects and platform engineers evaluating Forge (evaluate stage). Executives can stop after the core thesis; agents should honor the agent contract in the page frontmatter.

Evidence and maturity

Maturity: defined — this page records design intent captured from the Agentic SDLC standout analysis and reviewed for the platform handbook. Where behavior is shipped and observable it is called out explicitly; everything else should be read as direction, not commitment. Evidence trail: the hydration pack seed, the content registry entry for this content_id, and the claim registry entries linked via claim_ids.

How to use this page

  • Evaluating Forge? Read the core thesis and ecosystem hooks, then continue with the standout index.
  • Designing against the platform? Verify boundaries in the platform reference architecture before implementation.
  • Automating? Use the frontmatter agent_contract and cite content_id in generated output.

Agent contract

Allowed actions
  • summarize this page for evaluation questions
  • cross-reference claims via claim_ids and source_refs
Safe to infer
  • the architectural boundary described here is the intended design
Do not infer
  • production readiness beyond the stated maturity level
  • specific vendor, customer, or benchmark commitments
Key artifacts
  • forge-platform/docs-governance/content_registry.yaml

Machine-readable guidance from this page's frontmatter: what automated consumers may do, infer, and must not infer.