Early. Phase 1 of 3 in progress.
AI agents write the code. Foundry keeps the record.
Foundry is the record, evidence and safety layer for software built with AI coding agents. It works on top of Claude Code, Codex and GitHub. Your agents keep working the way they do. Foundry keeps durable checkpoints, local session visibility and owner-mediated project messages. Its release workflow checks evidence for the exact code and asks for your signed approval.
Illustration Agent sessions branch into their own worktrees and converge on one signed tree at a human gate.
The problem
AI coding agents are fast. A session can plan, write and test a feature in an afternoon.
But the work is fragile:
- It isn't durable. What the agent knew lives in a chat window. Close it, hit a limit or switch machines, and the next session starts from nothing.
- It isn't reviewable. Afterwards, it is hard to say what the agent actually did: which files it read, which commands it ran, what failed.
- It isn't safe to merge. The agent that wrote the code often tests and approves it too.
A review of yesterday's code is quietly reused for today's. Secrets sit one
cat .envaway.
Teams end up choosing between speed and trust. Foundry is built so you don't have to.
What you get
Six pillars
-
Continuity
Tasks, handoffs and decisions are written to your repository, not to a chat. Any agent, any tool, on any machine, picks the work up cold.
Example A session ends mid-task. The next one reads the task record and the last handoff, and carries on. This is how Foundry's own development has moved between two computers with no shared chat history.
-
Observation
Import supported Claude Code and Codex transcripts to record reported prompts, tool calls, file changes and failures. Configure supported hooks or import explicitly; coverage depends on available transcripts. Risky actions are flagged. Observation does not block actions.
Example
foundry observe flagslists recorded flags for sessions that touched a secret file, force-pushed or rewrote history, so you know where to look before you approve anything. -
Secret safety
Foundry decides by file path alone, without opening the file. Files like
.env, private keys and credentials are kept out of governed checkouts and snapshots and refused at merge. Generated CLI settings add protection within the tool’s supported boundary. Recorded sensitive-file touches are flagged.Example
foundry secrets settings --writeturns the policy into Claude Code's own deny rules (and a Codex permission profile, in beta), so sessions you start by hand get the same protection. -
Evidence-backed releases
A release names the exact Git tree being shipped. Tests, reviews and your approval all point at that tree. If one byte changes afterwards, the old evidence stops counting.
Example
foundry releasechecks the evidence, asks you to confirm at your terminal, signs the approval with your SSH key, and opens a pull request. A GitHub check then verifies the signed evidence before merge. -
Independent review
Security and QA reviews come from separate agents in their own roles, never from the agent that wrote the code. A role cannot accept its own work.
Example In a native project,
foundry releaserefuses a Security review written by the wrong role, a review accepted by its own author, or a review of a different tree. -
Token-conscious building
Read the context the task needs, write concise handoffs, delegate when it helps, and run focused checks. Reuse evidence while it remains valid. Required safety checks and independent reviews take priority over token savings.
Example A small fix starts with the affected files and the last handoff. The agent checks the changed behavior and records what it verified, so the next session can continue without rereading the whole project.
Evidence-backed releases · interactive demo
Evidence binding
Tests, reviews and your approval all point at that tree. If one byte changes afterwards, the old evidence stops counting.
tree
4a7d0c2e91b3f58e0c6a1d9b27f43e8c51a0d6f2
illustration
- Testsfull suite on the exact treenames tree
4a7d0c2e91b3 - Security reviewseparate agent, own rolenames tree
4a7d0c2e91b3 - QA reportseparate agent, own rolenames tree
4a7d0c2e91b3 - Your signed approvalyour SSH keynames tree
4a7d0c2e91b3
evidence complete
How it works
From a session to a gated pull request
-
Start a session
You open Claude Code or Codex in your project and boot the project's Orchestrator, Moonlight. Use
foundry bootfor a read-only briefing from local records andfoundry checkpointto save an explicit handoff at the end.PLANNED One-word orchestration ('Moonrise') remains planned across arbitrary editors; the boot and checkpoint CLI is shipped.
-
Define the task
The Orchestrator writes a task with a goal and completion criteria, and splits it into workstreams. Each workstream has one role and the files it owns.
-
Specialists build in isolation
Each specialist (backend, frontend, docs …) works on its own branch in its own Git worktree, so agents never edit the same checkout. Each one ends with a written handoff.
-
Independent review
Separate Security and QA agents review the exact candidate tree and register their reports as evidence.
-
Your signed approval
You run
foundry release. It shows what will ship, you confirm, and it signs the approval with your SSH key. No agent can do this step for you. -
A gated pull request
The release opens a pull request with a signed evidence bundle. A GitHub check verifies it before you merge.
A replay, not a live system. Output shapes from docs/walkthrough/07-release.md
(native release, abridged).
Agents propose. Your key approves. GitHub merges.
Proof
It's already shipping
Foundry is used on real work every day, including its own.
- 3production releases of an internal platform
- 4Foundry releases through
foundry release - 4governed projects
- ~25recorded gaps from real use
-
Gait: moving forward with Foundry
Foundry helped move Gait, an authentication and observability platform, forward through three reviewed production releases: GAIT-5, GAIT-10 and GAIT-11. Each one went the full path: Security and QA reviews from identified agent sessions, the human's signed approval, a
foundry releasepull request that passed the GitHub evidence check, then deploy to staging and production and smoke checks. -
Foundry ships Foundry
Four Foundry releases have gone through
foundry release, including Phase 1's own release. On 9 October 2026, Foundry's pull request #2 was the first to pass the live GitHub evidence check. Two other release attempts were stopped by Foundry's own checks before anything reachedmain. -
MiniEHR: a live website built with Foundry
MiniEHR’s live website, tutorial and synthetic demo were built using Foundry’s supervised workflow for a small C#/.NET EHR project. The patient and encounter demo is read-only; backend connection is pending. It uses synthetic data only and makes no healthcare certification claim.
-
Four projects are under Foundry today
Foundry itself, the Gait platform, a portfolio demo project, and a second application whose setup is pending.
-
Real use finds real gaps, and we write them down
About 25 product gaps reported by the teams using Foundry on these projects are recorded, each with a proposed fix. Most are scheduled in the next milestones.
Figures as of 9 October 2026, from Foundry's audit records.
Where we are
Foundry is early. Phase 1 (product core) is in progress.
Status checked 13 October 2026. SHIPPED means released on main; IN BUILD includes reviewed work awaiting owner signature and release. Maven has a report adapter; a Java worker and real Java worker build proof are not supplied.
| Area | Capability | Status |
|---|---|---|
| Continuity | Tasks, workstreams, handoffs, decisions and an event log in the repository; foundry status and foundry recover | SHIPPED |
| Observation | foundry observe records Claude Code and Codex sessions, with flags and an HTML report | SHIPPED |
| Secret safety | Path-based secret guard (secret enforced, sensitive observed); Claude Code settings; Codex profile in beta | SHIPPED |
| Human authority | Named humans, SSH-signed approvals bound to an exact commit, signed policy changes | SHIPPED |
| Releases | foundry release through a pull request with a signed evidence bundle; the GitHub evidence check | SHIPPED |
| Review rules | Native releases refuse wrong-role, self-accepted or wrong-tree reviews; gates by risk (docs-only changes need only your approval) | SHIPPED |
| Host guard | Claude Code deny rules for commands that change your machine (not a sandbox) | SHIPPED |
| Faster testing | foundry test --changed and the full suite in parallel in CI | SHIPPED FND-11a |
| Release polish | Clearer release prompts and safer reruns | SHIPPED FND-10.4 |
| Review sessions | One command to start a Security or QA review session | SHIPPED FND-12a |
| Moonrise / Moonset | Read-only foundry boot briefing and explicit foundry checkpoint records; no automatic editor integration | SHIPPED FND-12b |
| Token-conscious defaults | Advisory habits for scoped context, useful delegation and focused verification | SHIPPED FND-19 |
| Risk-based testing | Target-owned Python test plans with evidence bound to the source and plan | SHIPPED FND-11b |
| .NET builds | Whole-solution test evidence and an optional .NET SDK worker, verified with real C# tests | SHIPPED FND-16 |
| Healthcare profile | Optional synthetic-only data instructions and a read-only privacy reviewer; no compliance certification | SHIPPED FND-17 |
| Agent instructions | Trusted role and profile instructions included in governed Claude runs | SHIPPED FND-18 |
| Host scheduling | Heavy jobs queued so parallel sessions don't overload one machine | PLANNED FND-13 |
| Findings register | Findings and task state kept by commands, not by hand | PLANNED FND-14 |
| Deploy evidence | Backups, deploy and smoke results recorded with the release | PLANNED FND-15 |
| Application add-ons | Authentication and realtime integrations remain planned; released catalog/planning commands are advisory and adapters remain unverified | PLANNED |
| Usage and cost | Provider-reported token and USD subtotals with explicit unknown and partial coverage; no inferred billing or comprehensive cost claim | SHIPPED Phase 1 |
| Install anywhere | Broader public package distribution and stack onboarding; local uv tool install and foundry init are available today | PLANNED Phase 1 |
| Local mailbox | Owner-authenticated foundry message CLI and finite loopback inbox UI; incoming routes require receiver-owner approval. Explicitly save the enrolled mailbox location; provider-independent informational references, no agent-to-agent automation. | SHIPPED |
| Session visibility | Finite foreground foundry status --watch; registered lifecycle and recorded-use age, tracked Foundry host/container workers and runtime session bindings. External editor/model working state stays unknown; binding does not prove which model generates content. | SHIPPED |
| Django evidence | Guarded native whole-suite evidence for standard serial Django 5.2 discovery, with a target-owned preset and supported pinned cleanup hooks. Owner-signed first-preset measurement is separate from merge approval; supported POSIX environments only. | SHIPPED |
| Shared runtime observations | Reviewed shared runtime observation view; owner signature and release pending. Existing released worker and session visibility remains available. | IN BUILD |
| Cross-editor orchestration | One-word Moonrise / Moonset orchestration across arbitrary editors and automatic agent mailbox coordination remain planned. | PLANNED |
Where we're going
Three phases
-
Phase 1 in progress
Product core
Someone who has never seen Foundry installs it into any repository and gets value in under an hour: install,
foundry init, a first agent task with a handoff, an observation record, the secret guard on, and afoundry releasemerge. -
Phase 2 PLANNED
Distribution
A Claude Code plugin for one-step setup. A GitHub Action that blocks a pull request with missing evidence. Codex at parity with Claude Code. Broader cross-editor orchestration beyond the released registered-session lifecycle and recorded-use views. Optional, stack-specific Auth and Realtime add-ons are planned for new-app setup or later adoption; the released read-only catalog and planning CLI do not install or verify adapters.
-
Phase 3 PLANNED
Proof
Three applications ship through Foundry, each with a written case study: what Foundry caught, what it cost, and what got in the way. One of them is built from an empty repository.
PLANNED
The end state, for a team
You open any agent CLI and say one word. The session knows the project, the task and who is working on
what. Agents work freely. Every session is recorded. Secrets stay out of reach. Nothing reaches
main without reviews of the exact code and a human's signature, and GitHub enforces it. When
something goes wrong, the record shows what happened.
Boundaries
What Foundry is not
- Not an agent. It does not write your code. Claude Code, Codex or another agent CLI does.
- Not a replacement for GitHub, CI or your editor. When one of them can enforce a rule, Foundry configures it instead of rebuilding it.
- Choose the execution boundary. Host sessions run as your user; command deny rules are guardrails. Governed container workers add a separate enforcement boundary. Secret exclusions and agent permissions still depend on the policy you adopt.
- Not a guarantee by itself. The GitHub evidence check only blocks a merge when branch protection makes it a required check. On a free GitHub account, private repositories cannot enforce that, so there the check is advisory.
- Not proof of who an agent is. Session authentication varies by execution boundary. Foundry-produced host and container sessions have project/task bindings; token access on a shared host remains a trust limit. These bindings do not prove which model generates content. Human release approvals use your SSH signature.
- Not finished. Phase 1 is in progress. Some steps described on this page are planned and say so.
FAQ
Questions
Does Foundry replace Claude Code or Codex?
No. Foundry sits on top of them. You keep using your agent CLI; Foundry adds records, observation, the secret guard, evidence and the release path.
Which agent CLIs does it work with?
Claude Code and Codex today. Both can be observed, and both get the secret policy in their own settings
(Codex's profile is beta). Foundry can also launch headless Claude runs. Codex run support and the host
guard for Codex are planned (Phase 2). The operating instructions are plain files that any agent able to
read AGENTS.md can follow.
Is my code sent anywhere?
There is no Foundry cloud service. Foundry runs locally; configured container workers, Git and your agent CLI may access their permitted services. Your agent CLI still talks to its model provider, as it does today, and your pull requests go to GitHub. Observation records stay in your repository, with credential-shaped strings redacted.
What does it cost?
Foundry is in private development. Public access and pricing have not been announced.
What do I need to use it?
Python 3.12+, Git 2.31+ and uv, an SSH key for signing approvals, and a GitHub repository
for the pull-request release and evidence check. Enforcing that check on private repositories needs a
paid GitHub plan. Today you can use uv tool install /path/to/foundry from a local checkout; public package distribution remains planned.
Does it slow my agents down?
Agents work as they do today; observation never blocks. The cost is in releases: code changes need independent review of the exact tree, and a fix after review means reviewing again. Targeted Python testing has shipped to reduce test time. Target-owned risk-based Python release evidence has also shipped; broader evidence carry-over remains planned.
Can I use it on an existing project?
Yes. foundry init adopts an existing repository without moving its files. That is how the
internal platform and the portfolio demo project were brought in. Guarded target-owned .NET and Django evidence presets are available. Broader stack coverage
and application add-on recipes remain planned.
Does Foundry know what every agent is doing?
Status shows tracked workers, registered session lifecycle and eligible recorded use. A live process or project/session binding does not prove model activity or which model generated content. External editor sessions are untracked unless registered; prompts and tools require supported transcript ingestion.
Can projects exchange messages?
The released local mailbox CLI and loopback inbox use owner authentication and receiver-approved routes. Save an explicit mailbox location after enrollment. Messages carry informational task and artifact references; receipt grants no approval or authority. Automatic agent-to-agent coordination is planned.
Which test stacks are supported?
Python pytest, whole-solution .NET evidence and guarded standard Django 5.2 serial suites have specific evidence contracts. Django presets and dependencies are target-owned; supported pinned cleanup hooks and owner-authorized first-preset measurement have additional checks. Maven has a report adapter, with no Java worker build proof supplied. This is not universal language or framework support.
Follow along while we build it.
Foundry is in private development. We are shipping it on our own projects first and writing down what breaks. Explore what is available today and what we are building next.
Explore the roadmap