Why agentic development needs platform discipline

Agentic development needs platform discipline because coding agents amplify whatever your platform already is. On a platform whose standards live in people's heads, agents produce more code that follows the conventions they happened to read, and every unwritten rule is broken a little more often. On a platform whose standards are written down and checked on every change, agents produce more code that meets the bar, and review becomes a matter of checking a contract and reading a plan. Add the platform's full context to every agent session, and the same discipline that keeps agents in line also makes them far more capable.

What changes when agents write most of the code?

Three things change at once.

Writing gets cheap. An agent can draft a feature, a migration or a refactor in minutes. A team that used to open a handful of pull requests a day can open many more.

Review becomes the constraint. The speed of a team is now set by how fast people can confirm that what the agent wrote is right. Every pull request still needs someone to decide it can ship.

Memory disappears. A person who has worked on a codebase for a year carries its unwritten rules around. An agent starts each session from what is in front of it: the files it opens, the prompt it was given and the tools it can call. Whatever is not in that context does not exist for it.

The third point is the one that makes discipline necessary rather than nice to have.

Why do agents drift without written standards?

An agent that is not told the rules infers them. It looks at the nearest example and copies its shape. That is often a good guess, and occasionally a very bad one.

• The nearest example wins. If the repository the agent opens first still uses the old deployment path, the new service will too. The agent has no way to know that repository was the exception.
• Variation compounds. Ten agent sessions asked to add ten similar services produce ten slightly different services, each consistent with whatever it read. Nothing pulls them back to one shape.
• Wiki pages are invisible. A standard written in a document the agent never opens has no effect on what it writes. Neither does a rule that lives in someone's head.
• Exceptions spread. An agent that sees a disabled test or a hand-edited pipeline step in one place treats it as the local convention and repeats it.

None of this is a flaw in the agent. It is doing what a new hire with no onboarding would do, at many times the speed.

Why doesn't more review fix it?

The obvious answer is to review harder. It does not scale. If agents open several times more pull requests, reading every line of every diff with the same care either slows the team back to its old pace or turns review into a rubber stamp. Neither is what you adopted agents for.

The better answer is to move everything that can be checked by a machine into checks, so that human review is spent on the questions only a person can answer: is this the right change, and is it what we meant?

How does platform discipline change review?

In a disciplined platform, a reviewer of an agent's pull request does not start from the diff. They start from three artefacts the platform has already checked.

Review shrinks from "is every line right?" to "is this the change we wanted?", which is the question a person is actually good at.

Bound the work before it starts

An agent given an open-ended prompt can change anything. An agent given a task contract has a ceiling.

A task contract lives in the repository as tasks/<KEY>.TaskContract.yaml. It states the goal in a sentence, the paths or components the work may touch (affects), what done means (doneWhen), and the checks a merge must pass (gates). orun task check compares the diff with the contract before the pull request exists, and Orunbase checks it again on the pull request. If the work honestly needs to grow, the contract is widened in the same pull request, in the open, rather than silently.

The contract also decides when the work is finished, and the agent does not. Nobody, person or agent, can write a task's status. It moves from in_progress to in_review to done because the platform observed a branch, a pull request and a merge whose gates passed. An agent cannot declare victory. The evidence does.

When orun runs the agent itself, through its agent runtime, the contract becomes part of a sealed brief, and the agent type declared in the repository sets a deny-by-default policy for which tools it may call, must ask about, or may never call.

Know who did what

When many changes are opened by agents, "who made this and why?" stops being a casual question. Platform discipline answers it the same way for every change:

• The branch is named orun/<KEY>-<slug>, so the platform knows which task it belongs to.
• Every commit carries an Orun-Task: <KEY> trailer.
• One pull request serves one task.
• The pull request body carries a manifest naming the task, its epic and the skill revisions the session followed.

Orunbase's orun/compliance check verifies all of it on every pull request, and it applies the same rules whether a person or an agent opened the pull request. Guardrails that only bind people, or only bind agents, are not guardrails.

Give agents the platform, not just the repository

Discipline keeps agents inside the lines. Context is what lets them do something useful once they are there.

A repository tells an agent about itself. It does not say who owns the service next door, what depends on the package it is about to change, why last night's production deploy failed, or which task this change is for. Without that, the agent guesses, or a person pastes the answers into the prompt by hand.

Orunbase serves the platform to agents over MCP. An agent connected to a workspace can search the service catalog and follow its dependencies, read run history and the logs of a failed job, fetch a task's contract and its current state, and ask questions in plain language that come back with passages citing the entity, file and commit they came from. The team's playbooks are served as versioned skills, so the agent follows the same procedure a colleague would, at a revision it records. Every call runs with the agent's own credential and the workspace's access rules. The next post goes through the tools in detail.

Disciplined, and more powerful

It is tempting to see discipline as a brake on agents. It works the other way round.

Written, checked standards make an agent's output predictable: it follows the golden path because the plan will not compile otherwise. Full platform context makes the agent capable of work that crosses the boundary of one repository. Together, they let you hand agents tasks you would not trust them with otherwise:

• Fixing a failed deploy. The agent reads the failed run and its logs, finds the component and its owner in the catalog, opens a task with a contract, and proposes a fix that the plan and the compliance check both verify.
• Upgrading a golden path everywhere. Because golden paths are pinned versions, the upgrade is one small, reviewable pull request per repository, each with its plan diff, rather than a hand-edited migration.
• Planning, not just coding. An agent can break a piece of work into tasks with contracts under an epic, so the work that follows is bounded before anyone writes a line.

Each of these is safe because the standards hold whoever does the work, and possible because the agent can see the whole platform.

A checklist for an agent-ready platform

1. Every component names a golden path, checked on every pull request.
2. Every change compiles to a plan a reviewer reads before it runs.
3. Every piece of work has a task contract with a ceiling on what it may touch.
4. Task status comes from observed evidence, never from a field anyone can set.
5. Branch names, trailers and the pull request manifest tie every change to its task, and a check verifies them for people and agents alike.
6. Agents connect to the platform over MCP with their own credential, and read the catalog, runs, tasks and playbooks rather than guessing.
7. The rules you care about are enforced, not only written down.

In short

• Agents make writing code cheap and review the bottleneck; they also start every session without memory.
• Without written, checked standards, agents copy the nearest example and drift multiplies.
• Platform discipline moves the checkable parts of review into checks: the contract, the plan, the golden-path schemas and the lineage.
• Task contracts bound an agent's work, and status is derived from evidence, so an agent cannot declare its own work done.
• Orunbase's MCP tools give every agent the platform's full context, which turns disciplined agents into capable ones.

For the groundwork, read what platform discipline is and how it proves code quality.