AI Factory · Getamazednow AI

GOVERNED AGENTIC DELIVERY

Labelled issue in. Reviewed pull request out.

AI Factory turns a GitHub card or issue into a pull request your team can trust: planned against your requirements, built behind hard gates, and delivered with the evidence to prove it.

Models plan, write and review. Tested code decides everything else. And nothing reaches main until a person merges it.

≤ 13model calls per run, every one capped

≤ 7gates on every commit, bound to that exact commit

0network access where your repo's code runs

6evidence sections in every pull request

THE PROBLEM

Agentic coding is fast. Unchecked, it is a liability.

A coding agent can draft a pull request in minutes. Left to itself, it also decides what to do next, runs tools with live credentials, and judges its own work. For a team that has to answer for its code, that is three risks in one.

01

Self-graded work

An agent that writes the code and decides it is done has marked its own homework. Nothing independent says the work meets the requirement.

02

Untraceable changes

A change nobody can trace to a requirement or a decision is a change nobody can defend in review, in an incident or in an audit.

03

Code beside credentials

Untrusted code running next to tokens and an open network is how a supply-chain incident starts.

THE DIFFERENCE

Same speed. A different contract.

AI Factory keeps the speed of an agent and takes away the parts that make it risky. Every row below is enforced in code and tested by switching it off.

	An unconstrained coding agent	AI Factory
Who decides the next step	The model	Tested code, routing on recorded state
What the model can do	Call tools, retry, fetch more context	Return one validated object, within a capped number of calls
Where your code runs	Often beside credentials and a network	In a hardened container with no network and no token
What the pull request proves	What the agent says it did	Six evidence sections, built from the run's own records
When it is unsure	Guesses and carries on	Raises a decision issue and pauses for your approver
Who merges	Whoever its token allows	Always a person on your team

BUILT FOR

Built for teams that answer for their code

Agents build. Code decides. Humans own the result, and everyone who has to sign it off can see why.

Engineering leaders

Card-sized work arrives as a pull request that is already planned, gated and explained, so review time goes on judgment, not archaeology.

Platform and security

Two separate identities, read-only single-repo tokens, no network where code runs, and every external effect through a named tool.

Risk and audit

A record of every run, a decision issue for every judgment call, and a named person accountable for every merge.

THE PIPELINE

Every stage of a run

One pipeline, bound to your repository's own governance policy. Most stages make no model call at all.

Governance preflightYour repo's own checker runs on the base commit, first, every time.

IntakeTen checks before anything is planned: the right label, locked requirements, every named file present, nothing on hold.

ContractA frozen task contract carries every requirement and constraint ID through the run.

PlanA plan citing only IDs that exist in your files, with a test or checkpoint for every criterion. Checked by code; re-planned on failure.

Code and gatesWrites only the files the plan allows. Every commit runs the gates in an isolated sandbox.

Pull requestOpened with six evidence sections, then one advisory review comment.

Filled dot: a stage that may call the model. Every other stage is deterministic code.

THE CONTRACT

A frozen contract drives every move

The task contract cannot be edited once created. Its status changes only through named, checked transitions, so a run can never wander into a state nobody designed.

The path to a pull request

1ReceivedThe contract is built from the checked intake record.

2PlanningThe plan, or for a later pull request, the stored plan record.

3Coding and gate checkThe coder commits; the gates run on that exact commit.

4Opened and reviewedThe pull request opens with its evidence; the reviewer comments.

Gate failures loop back to CODING; the third strike stops and asks you.

THE REVIEW LOOP

Request changes. It revises the same PR.

Review the pull request the way you review a colleague's. When you request changes, the factory revises the same branch, refreshes the evidence, and answers each of your comments with the files it changed and the new commit.

What countsOnly your latest “Request changes” on the current head commit. Comments alone never trigger work.

What it touchesOnly the files already in the pull request. A request that needs more is handed back to you as your decision.

What it postsEach of your comments with its response, the files changed and the new commit, plus refreshed evidence.

Only your latest "Request changes" on the current head counts, and the branch must be up to date.

AGENTS WITH LIMITS

Extractors, not tool-callers

Each model-backed agent has one job, one structured output and a cap on its calls. What it may never do is enforced by code, not by its instructions.

≤ 1

Product manager

Builds the task contract. Never drops a constraint.

≤ 3

Architect

Plans the work. Never cites a requirement your files don't contain.

≤ 5

Coder

Writes the pull request. Never writes outside its allow-list.

≤ 3

Design reviewer

Checks against your design system. Advisory; never blocks.

1

Reviewer

Reviews the diff against the contract. Never merges.

0

Escalation

Asks you to approve or decline. Never approves itself.

YOUR POLICY, ENFORCED THREE TIMES

Fail loud. Omission is safe.

Every repository has a policy file that decides what the factory may write. No policy means no writes at all. Three independent layers check every write against it.

Fail loudA response that doesn't parse is logged and stops the call. It is never replaced with a default.

Omission is safeAn agent that cannot ground an answer leaves it out. The planner never invents a command your project doesn't define.

Protected pathsYour requirements, governance files and workflows are never written. An attempt ends the run, and is never retried.

Each layer loads the policy itself. A protected path is never written, whichever layer catches it.

DECISIONS

It asks instead of guessing

When a plan needs something only you can decide, such as a new dependency or work that traces to no requirement, the factory raises a decision and pauses before any branch exists.

How a decision works

1A decision issueA question, the options, a recommendation and the consequences, in a fixed format.

2Your answerOnly your named approver's label counts. Comments never do, and an edited issue keeps the card stopped.

3RecordedRe-run the card to resume. Each accepted decision lands in the pull request as an architecture decision record.

ESCALATION

It stops and asks. It never retries silently.

Three separate budgets, never mixed. When one runs out, the run comes back to a person.

3

Code failures

A real gate failure is a strike against the coder. The third brings you in.

3

Infrastructure failures

Retried on the same commit, and never counted against the coder.

3

Planning failures

Re-plans and scope changes. At the limit the run ends, and approval never resets it.

ZERO TRUST

Two identities, never one

The part that thinks and the part that runs code are separate identities, and neither is ever widened to work around a problem.

Control planeCalls the model and mints short-lived credentials. Runs on hardware you hold.

Execution planeHas no access to cloud data at all. It never mints a credential; it only receives one short-lived value.

Tool accessEvery external effect goes through a named tool on a named server. Each step gets one narrow adapter that refuses anything outside its allow-list before any request is made.

Only a stateless request for text leaves for AWS. Repo code runs only where there is no network and no token.

THE SANDBOX

No network where code runs

Every gate that runs your repo's code uses two hardened containers. Nothing from your repo or its dependencies ever runs where there is a network or a token.

Install

Clones the exact commit and installs dependencies with install scripts switched off, through a private package proxy only.

Run

Runs the one command with no network at all, and refuses to start if a network interface is up.

Harden

Read-only file system, every capability dropped, no privilege escalation, a non-root user and a time limit per check.

CREDENTIALS

Tokens that cannot push

Anything that touches your checkout gets a token that can read one repository and nothing else.

Read-onlyEvery token near repo code is scoped to read the one target repository. Anything broader is refused before it's used.

Never storedTokens never land in the git configuration, and are removed before any repo code could run.

Untrusted lockfileThe dependency lockfile is produced in the sandbox and validated as untrusted input before anything is committed.

Stateless model callsOne structured request in, one validated object out. The model provider holds no session, memory or credential.

EVIDENCE

Every pull request proves itself

The pull request body is built from the run's own records, without a model, and refreshed after every revision. Six sections, every time.

1

Card and requirements

The card, this PR's place in the sequence, and every requirement it delivers.

2

Acceptance checklist

Each criterion ticked only when its test exists and passed at a named commit.

3

Checks

Every gate's last result and commit, and any failing output.

4

Visual checkpoints

Where visual acceptance is still a person's job, it says so.

5

Decision records

The decisions accepted for this card, linked.

6

Dependency changes

From the lockfile diff, with any escalated change and its decision first.

THE PLAN RECORD

One plan, many pull requests

Large cards ship as a sequence of pull requests. Before the first one, the whole sequence is posted on the card with a fingerprint.

How later pull requests stay honest

1Posted onceThe plan and its fingerprint go on the card before any branch exists.

2Verified each timeLater pull requests are built from that record only if it was written by the factory, never edited, and its fingerprint matches.

3Re-checked at every baseIf the stored plan no longer fits your repository, the run stops and asks you.

AUDIT TRAIL

Nothing happens off the record

Every run writes down what it read, what it decided and why it stopped. Your repository carries the same story where your team already works.

IntakeThe base commit, the policy fingerprint, the requirements read and their fingerprints.

PlanningEvery planning attempt, its failures and the decisions it raised.

ViolationsAnything refused, with the policy fingerprints of both sides.

On GitHubThe plan on the card, decision issues, the evidence in the PR, the reviewer's comment and the answer to your review.

BRING YOUR REPO

What your team provides

The factory works only from what your repository states. Setting that up is a short, one-time job.

Getting a repository ready

1Install the GitHub AppWith read and write access to contents, issues and pull requests on that one repository.

2Write the requirementsConstraints, one feature file per card, and the decision points and acceptance checkpoints your cards cite.

3Lock themA lock approving each requirements file, and a governance checker the factory runs on every commit.

4Write the policyWhat the factory may never write, reviewed like code.

5Dry-run firstIntake only, then plan only, before the first real run.

Contact us →

ON GITHUB

Where it shows up

Everything the factory does is visible in the places your team already reviews work.

On the cardThe pull-request sequence and plan record; why a run stopped, if it did.

Decision issuesA question, options, a recommendation and how to answer.

In the pull requestThe six evidence sections, refreshed after every revision.

As commentsThe reviewer's advisory review, and the answer to each of your review comments.

NeverA merge, a deploy, or a push to main.

PROOF

We test the safeguards by switching them off

A safeguard that no test notices is decoration. Each one is disabled, alone, in a copy of the code, and the whole suite is run. Every one must make a test fail.

277 / 277

Switch-offs caught

Every safeguard switched off across eight build stages was caught by the suite.

618

Tests

No network and no live model: GitHub, the sandbox and the model are all stand-ins.

Every

Decision recorded

Each design decision is written down with its reasoning before it's built.

NEXT STEP

See it on your repository

Tell us about the repository you have in mind, and how your team reviews work today. We'll come back to you directly.

Contact us →

Questions about security or data first? Read Trust & Security and our Privacy Policy.