What BPOS runs · 2 · Plan
Every job is a contract.
Written before the work, judged after it.
An agent that starts from a vague request finishes with confident work nobody asked for. So in BPOS no job starts without a contract. This is what the contract holds, how it is written, how it travels into every prompt, how it is judged, and where ours are still weak.
In BPOS, a job is a contract: what to do, the acceptance criteria it will be judged on, the jobs it waits for, and where it works. Before any work starts, the contract becomes the job's COCA frame (Context, Objectives, Constraints, Action), placed at the top of every prompt the job produces.
This is the second article of What BPOS runs. The first, A goal has necessary stages, covers how a goal becomes a program of stages. Each stage becomes a blueprint of sprints and jobs. This article is about the job.
Why a contract: spec-driven development, run
In May 2026, Addy Osmani, Shubham Saboo and Sokratis Kartakis at Google published The New SDLC With Vibe Coding. One of its central moves is to treat tests and evaluations as a contract with the AI, written before the implementation, not after. Its closing line puts the shift plainly: "Generation is solved. Verification, judgment, and direction are the new craft." Rahul Gite's write-up is a good way in.
The same month, Kapil Viren Ahuja proposed IDSD in The Method That Replaces Spec-Driven Development (Activated Thinker, Medium): hand a harness an Intent, a Context and its Expectations, and let it retry until the expectations are met. His enemy is the agent that is confidently wrong. That is close to the COCA frame below. He leaves context and expectations to a later piece; in BPOS all three run in production.
What a contract holds
- What to do: a title and a description.
- Acceptance criteria: the checks the job will be judged on, about four per job.
- Waits for: the other jobs it depends on, when there are any.
- Carries: the repository it works in and the skillset that shapes how it is done.
In the 30 days to 9 October 2026, BPOS created 529 jobs. All 529 had acceptance criteria and a description. 85% named a repository, 57% carried a skillset, and 63 waited on other jobs.
How the planner writes it
The planner writes every contract when it generates a blueprint. It does not write from a blank page. It is shown how the last 40 blueprints were shaped and how they scored, the good shapes and the bad ones, and told to break work into two or three jobs per sprint across several sprints rather than one coarse job. Shape is something the record can teach, so the record teaches it.
It is also meant to be shown which acceptance criteria fail most often, so it can add them to new contracts. That feed has been empty: the scorer stores each judgement with capitalised field names and the planner's query asks for lowercase ones, and since 27 September a handful of empty records make the query fail outright. We found it while checking this article. It is the next fix.
The frame: COCA
A contract on its own is a record. To reach the agent it becomes a frame: Context, Objectives, Constraints, Action. BPOS builds the frame once per job and places it at the top of every prompt the job produces, constraints first. A job is worked by many small steps, and every one of them sees the same contract. A step adds only its own local rules; it never rewrites the job's.
Action is a perception modifier. It does not describe the work; the objectives do that. It shapes what a step believes it can do besides producing its answer.
We learned why the hard way. In September, Action described the work in seven fields, and not one of them described a move. A step could ask the platform for a reading, or declare that its instructions could not all be met, but nothing at the top of its prompt said so. In 85 of 85 cases the platform served a reading that no step had asked for. A page explaining how to ask did not help: placed in the middle of a 34,678-byte prompt, it was outranked by the step's own constraints and objective, and the step that received it did not ask.
So Action now names the moves in the part of the prompt that outranks everything else: ask for a reading, or say you are blocked. And it names them only when they matter: when a reading the step was promised could not be delivered, or when names the step needs appear nowhere it has read. A move offered when it is not needed is noise that competes with the task.
It was not enough on its own. In the 21 days after the moves were named, 87 worker turns met exactly the situations they were for, and not one asked a question. Which is why reading became a turn of its own for every node, as What a node reads before it acts explains.
How acceptance criteria are judged
After the work, a judge model checks each acceptance criterion. One judgement can flip on noise, so each criterion is judged three times independently and the majority decides. The job's score, EQS, is the share of its criteria that passed. In the 14 days to 9 October, 1,045 criteria were judged this way and 84.6% passed. Work that fails the check declared for its kind of file scores 0, whatever its criteria say. What happens next, a commit on its own or a person, is in the overview.
Where our contracts are weak
- Some criteria ask too little. About 1 in 6 of the criteria judged in those 14 days (15.9%) only checked that a name exists in the code, such as "Contains `SiteSwitcher`". It passes when the name is there, whether or not the thing works. A contract is only as good as what it asks.
- The planner does not yet learn from failing criteria. The feed described above is empty, so contracts do not yet get stronger where they most often fail.
- A contract is not free. Writing one pays on work that repeats or that must not break. On one-off exploration it can cost more than it saves, and we do not write them there. Clarify before you build covers the evidence on both sides.
Common questions
What are acceptance criteria for an AI agent?
The checks a job will be judged on after the work, written before it starts. In BPOS every job has them, about four per job, each judged three times by a judge model; the job's score is the share that passed.
What is in a BPOS job contract?
What to do, as a title and a description; the acceptance criteria the job will be judged on, about four per job; the jobs it waits for; and, for most jobs, the repository it works in and the skillset it carries.
What is the COCA frame?
Context, Objectives, Constraints, Action: the job's contract turned into one frame, built once per job and placed at the top of every prompt the job produces, constraints first. Action is a perception modifier: it names what a step can do besides answering, such as asking for a reading or declaring itself blocked, and only when that move matters.
How are acceptance criteria judged?
After the work, a judge model checks each criterion three times independently and the majority decides. The job's score is the share of its criteria that passed.
Sources
- Addy Osmani, Shubham Saboo, Sokratis Kartakis, The New SDLC With Vibe Coding, Google, May 2026; via Rahul Gite, "What Google's New SDLC Paper Got Right About AI-Assisted Software Development", Level Up Coding, September 2026.
- Kapil Viren Ahuja, The Method That Replaces Spec-Driven Development: IDSD, Activated Thinker (Medium), May 2026.
- Our own records, as of 9 October 2026: jobs created in 30 days and their contract fields; acceptance criteria judged in 14 days, their pass rate and form.
Related writing
- BPOS: how we build software with agents. The whole machine, and the series this article belongs to.
- A goal has necessary stages. The program a job's blueprint comes from.
- Clarify before you build. When a contract pays, and when it does not.
- The blast radius of a change. How far a job must reach, and what it must read.
- Nodes, not agents. Who carries the contract out, and what is kept of them.
- The quality gate. What happens to the work once its criteria are judged.
- LLM-as-a-Judge. How far a judge model can be trusted with the criteria.
- The Checklists That Did Nothing. An 88-execution experiment in which skill checklists changed nothing.