01 / 13
Claw Forge

Autonomous delivery
that survives the
security review.

An engineering brief for global systems integrators — how many parallel AI agents ship verified work across hundreds of client engagements, without a single line of client code pooling anywhere it shouldn't.

Audience · Delivery & security leadership Version 1.11.0
02The problem

The pilot doesn't die at the demo.

It dies three weeks later, in a room with a security architect and a delivery partner. The output was never the issue. These five questions were.

  1. 01Where does the client's code go?
  2. 02Can we report across engagements without pooling client IP?
  3. 03Whose model contract pays for it?
  4. 04Does it bypass the controls our SDLC depends on?
  5. 05When it goes wrong, how far does the damage reach?

Claw Forge answers all five with mechanisms that already ship — mostly built for reasons other than enterprise sales.

03The architecture

Isolated execution, centralised governance.

The instinct is to centralise the database so leadership gets one pane of glass. For a firm holding many clients' confidentiality obligations, that instinct is the risk — a shared task store spreads every engagement's obligations across all of them.

Engagement AAgents in isolated git worktreesstate.db · local SQLite
Engagement BAgents in isolated git worktreesstate.db · local SQLite
Engagement CAgents in isolated git worktreesstate.db · local SQLite
Nothing crosses but structure
claw-forge export
A pipe you own. CSV, SQL dump or JSON, straight out of SQLite with no service dependency. Your warehouse, your schema.
structural telemetry
Delivery metrics that are incapable of carrying code, paths or client names. Enforced at the write, not by policy.

Client segregation stops being a policy someone enforces and becomes a property of the architecture. There is nothing shared between engagements because there is nothing shared to begin with.

04Question 01
Containment

Seven layers between an agent and anything it shouldn't touch.

The OS-level jail is on by default — agent.isolation ships as sandbox, not none.

LayerWhat it actually denies
1File tools — Read/Write/Edit/Glob/Grep confined to the project directory
2Exempt-command jail — path arguments to git, npm, python checked too
3Prompt boundary — the parent project's path is deliberately never named to the agent
4OS filesystem jail — sandbox-exec on macOS, bwrap on Linux
5Container isolation — opt-in; the parent project is absent from the namespace entirely
6Supply chain — npm_ignore_scripts and home_protection both default true
7Vanished-worktree fail-closed — every tool denied the moment the worktree stops existing

Layer 6 is the one reviewers care about most and ask about least. A malicious postinstall runs as an npm child process, not as a command the harness sees — command-level review cannot catch it. npm_ignore_scripts stops it executing at all.

05Question 02
Governance

Report across the portfolio. Leak nothing.

Every telemetry envelope passes assert_structural on its way to disk, from spool.write, with no code path around it.

The rule is inverted

A leaf key that is not declared is a violation, not a pass-through. 91 declared keys, each with a declared kind.

No field can hold a secret

A path, repo name, branch, client identifier or error string cannot arrive by accident — there is no field shaped to receive one.

Labels never ship

Free-text feature categories are classified at the edge into a closed 30-value vocabulary. The original text stays on the machine.

Identity is derived

A random install UUID — never hardware, hostname or username — and HMAC-SHA256(install_id, repo_key) per project. The repo key is never transmitted.

Proof it's load-bearing, not decorative. The version-string grammar was tightened because an earlier pattern would have admitted free text after a leading digit. The worked example left in the source is a string shaped like 1-acme-bank-production-secret-name. A client name in a version field is precisely the leak this exists to prevent — and it was closed before it shipped.

06Question 03
Procurement

Your cloud agreements already paid for this.

Procurement is usually the longest pole. Eight provider types route through one pool — including the three you've already papered.

bedrockvertexazure anthropicanthropic_oauthanthropic_compat openai_compatollama

Mixed pools, one config

Route by priority, round-robin, weighted random, least-cost or least-latency. Every provider carries its own circuit breaker.

Exhaust the chain before failing

A rate limit on one account rotates to the next rather than ending the run. Capacity on an existing AWS or GCP agreement, with direct contract as overflow.

ollama covers the engagements where nothing may leave the building at all.

07Question 04
SDLC control

"Done" means verified — the harness doesn't trust the agent either.

ControlWhat it enforces
AcceptanceRe-runs the suite in the task's worktree after the agent claims success and before the merge. Non-zero exit returns the task to failed.
BaselineMeasures the same suite on the target branch in a throwaway worktree first, so inherited breakage isn't charged to this task. A bug fix is deliberately not forgiven — the inherited failure is its assignment.
AssemblyRuns on the target branch after everything merges. The one gate that can see integration, because integration only exists between neighbours.
Merge gateA dependent task waits until its parent is both completed and merged.
AttributionEvery failure records agent, infrastructure, integration or unknown — so a broken build box never reads as a bad model.

The success rate your delivery leads see counts only the failures the agent could have prevented. The denominator is always shown.

08Differentiator

Features and defects are one workflow, not two systems.

Most tooling treats the backlog and the bug tracker as separate worlds that reconcile in a status meeting. Here they share one session, one dependency graph, one lock namespace.

Lineage is real

caused_by resolves to the actual feature task that introduced the defect — not a free-text reference someone maintains by hand.

Collisions are structurally impossible

One file-claim namespace means a fix cannot be dispatched against files an in-flight feature already holds.

Mid-run injection

A defect planned while agents are working is picked up by the running dispatcher on its next wave. No restart.

Severity outranks the backlog

Bug priority maps above the entire feature range, so a critical defect pre-empts queued work instead of joining the back of the queue.

09Differentiator
Scale

Your system is a dozen bounded contexts. So is the plan.

Several specifications, run in sequence against one repository.

The limit was never the agent count

Past a few hundred features the constraint stops being the specification and becomes the run: merge catch-up grows, shared directories serialise, interfaces cannot be frozen mid-flight.

Disjoint roots, enforced

Each subsystem owns one module root, and roots may not overlap. Subsystems cannot collide — by construction, not by care.

after: is the contract freeze

The boundary between runs is where a human reads what the last one produced and decides the interface is settled. A dependency graph inside one spec cannot express that.

Every requirement has exactly one owner

Declared in umbrella.yaml, so claw-forge umbrella check reports the two failures no single specification can see: a requirement nobody owned, and one somebody claimed but never built.

Delivered, not designed. One logistics programme on this pattern carries 2,221 completed tasks across 138 categories — 16 subsystems, per-subsystem module footprints, dedicated integration runs for the cross-subsystem flows. Its brief estimated ~1,900 features; the delivered system came in above that. Counts read from the project's task database, not from the brief.

It does not design the decomposition — catalogue, contracts and run order are an architect's work, and that judgement is why it held. Claw Forge makes that structure checkable, not a table someone is trusted to have read.

10Question 05
Reference deployment

What this looks like across a delivery organisation.

ConcernWhere it lives
ExecutionPer engagement — one repo, one state.db, agents in worktrees
Model capacityPer-engagement pool config pointed at the firm's Bedrock / Vertex / Azure accounts
SecretsPer engagement, via ${ENV} expansion and a gitignored local overlay
Control planePer engagement, bound to loopback or behind a bearer token
ReportingScheduled claw-forge export --scope all into your warehouse
Audit trailEvent log plus agent transcripts, exported with the rest

Two defaults to change on day one. The state service binds 0.0.0.0 and is unauthenticated until you set CLAW_FORGE_STATE_TOKEN. And agent transcripts are retained in state.db by default — local and never transmitted, but retained. Set a retention window or disable them.

11Due diligence

What Claw Forge does not do yet.

Your review board will find this list. Better that it comes from us — the gaps are what make everything on the previous slides credible.

No shared control planeSQLite only; the Postgres extra was removed in 1.1.0 as advertised-but-incapable. The state service is single-process and file-claim atomicity depends on it. A multi-tenant store is real engineering, not a flag.
No RBAC or SSOOne shared bearer token — possession is authorisation. The audit trail attributes actions to tasks, not to people.
No portfolio rollupExport is per project. Cross-engagement aggregation is a pipeline you build.
No HA or failoverNo supported restore drill beyond the SQLite recovery path.
No compliance packageNo SOC 2 report, no penetration-test summary, no DPA to hand a client's risk team.
Unconstrained egressNetwork egress is only controlled in container mode.

None of these block an engagement-scale deployment, which is what Claw Forge is built for today. All of them matter if the goal is one shared platform across the whole firm.

12The ask

A pilot that answers the review board, not just the demo.

Days 1–30

One engagement, one squad

  • Deploy on a live delivery workstream
  • Loopback binding, token set, retention configured
  • Security review against slides 4–7
Days 31–60

Prove the governance pipe

  • Scheduled export into the firm's warehouse
  • First cross-engagement delivery dashboard
  • Verified-completion rate vs. baseline velocity
Days 61–90

Decide on the platform

  • Three to five engagements running
  • Evidence pack for the client-facing DD conversation
  • Scope the shared control plane — or decide you don't need one

The decision at day 90 is not "does it work". It's whether the gaps on slide 10 are worth funding for your firm's scale — answered with your own delivery data rather than a vendor's.

13Summary

Isolation is the product. Governance is the pipe.

Client code never pools

Per-engagement execution with seven containment layers, on by default.

Metrics cannot leak

91 declared fields, a closed vocabulary, enforced at every write.

No new vendor

Bedrock, Vertex and Azure through the pool you already pay for.

Verified, not claimed

Tests re-run after the agent and before the merge, with inherited breakage separated from regressions.

One workflow

Features and defects in one graph, one lock namespace, real lineage.

Honest gaps

No shared plane, no RBAC, no compliance pack — stated up front.

The full technical treatment is Part X of the Claw Forge handbook, Claw Forge in the Enterprise — including the configuration keys behind every control on these slides.