Engineering Standards › Team standardisation
Team standardisation
Standardisation exists because verbal instruction does not survive a time zone.
Work reviewed over someone's shoulder converges by the end of the day. The same instruction sent across a one-hour overlap window
diverges for weeks and surfaces at the wrap-up call. Every convention on these pages exists to move correctness out of conversation and into
structure that a reviewer can check without being in the room.
The delegation contract
The same specification discipline that makes a dispatched agent reliable makes a dispatched person reliable, for the same reason: vague delegation produces duplicated and misaligned work. Every assignment carries four things.
| Element | What it means for a person | What it prevents |
|---|---|---|
| Objective | The end state, stated so it can be checked. Not "integrate the graph" but "the deal agent returns relationship data from the graph for these three query classes, with these tests passing". | Two people confidently completing different tasks. |
| Output format | Which repository, which branch, which files, which structure. Named up front. | Work arriving as three separate repositories, then one merged repository, then a fragment sent overnight. |
| Tools and sources | Which environment, which credentials, which reference implementation to build on, which guide to follow. | A parallel build from scratch when an existing implementation was meant to be extended. |
| Boundaries | Explicitly what is out of scope. "Change nothing else" is a boundary and must be written down. | Scope expanding from one integration into tens of thousands of lines of unrequested code. |
Review cadence, not review events
- Chunk the work so each piece is verifiable in a day or two. A chunk that cannot be reviewed until it is finished is a chunk that will be finished wrong.
- Review the structure before the content. Folder layout, constitution, skill placement and agent definitions are checkable in minutes and predict everything downstream. A cluttered tree is a reliable early warning.
- The gate is mechanical where it can be. Hooks and CI check layout, schema, isolation and eval regression, so review time goes to judgment rather than to formatting.
- Escalate at the second divergence, not the second month. The escalation is a specific, unembarrassing message: here is the expectation, here is the delivery, here is the gap, I need help getting the point across. Waiting is the expensive choice.
- Nothing is thrown away silently. If work is not going to be used, that is a decision made openly and early, with the reason recorded, not discovered at the end. Discarded work is a management outcome, not an individual one.
- The reference implementation is the teaching tool. Point people at the master project and the skeleton rather than describing them; a stamped tree communicates in seconds what a call communicates in an hour.
One word, one meaning
Terminology drift is not pedantry, it silently misconfigures systems. A single use case described as a "project" produced a tree of per-use-case constitutions and a misconfigured agent, and the cost was two months of divergent work. The glossary is the authority; a single gatekeeper owns changes and everyone proposes by pull request.
Project. The whole engagement. Not a use case, not a repository, not a workstream.
Use case. One output the platform produces. Gets one skill folder, never its own constitution.
Agent. A defined unit of judgment with an objective, output format, tool guidance and boundaries. Not a script, not a workflow.
Workflow. Deterministic multi-step code. Not an agent, however many model calls it happens to make.
Roles on a staffed project
| Role | Owns | Hands off |
|---|---|---|
| Environment engineer | The harness: routing, observability, evals infrastructure, secrets, tenancy, CI gates, the skeleton itself. | A stamped, instrumented environment with the gates live. |
| Solution engineer | Skills, agent definitions, workflow logic, and the deterministic-versus-agentic call for each step. | Use cases that pass the eval gate and slot into the plane unchanged. |
| Knowledge owner | Ontology releases, rubrics, golden exemplars, the promotion gate. | Versioned releases the solution layer pins. |
| Client-facing lead | Discovery, the right questions, the binding values, translating outcomes into activation and orchestration choices. | A filled binding and an agreed set of gates. |
Each role's output is the next role's input. The playbook is what makes that hand-off checkable rather than conversational, which is the entire reason it exists.