We hire people who want to build with agents — not only use them. We work like an ordinary, well-run engineering team, but supervised AI agents do most of the work at every stage. Humans own prioritisation, quality, and what reaches customers. Home care is the hard real-world domain where the workflow has to prove itself.
Build-first means: plan before code, small vertical releases, traceability, and human responsibility before automation — the same habit of learning from outcomes as the product itself.
We write down goals, risks, and user value before agent flows implement.
AI can produce a lot, but code, design, content, and data flows are reviewed as product work.
Home care is the proving ground: planners, caregivers, clients, and family — not a demo sandbox.
We prefer useful improvements that can be tested, measured, and improved over large opaque leaps.
Delivery mandate
Product owners describe the change with goals, non-goals and acceptance criteria. Coding agents plan, implement and verify it in an isolated working copy, behind the same quality gates as all other code. Humans own priority, architecture and the production release.
What we measure
We measure like any delivery team: lead time to the main branch, first-pass yield and change failure rate — plus model cost per change. The point is not replacing product judgement; it is removing avoidable handoffs from work that has already been specified.
Workflow
Each stage is a familiar software-engineering pattern with a gate; the next stage does not start until the gate is passed. What changes is who performs it: agents do the work, humans own the decisions.
| # | Stage | Performed by | Human role |
|---|---|---|---|
| 0 | Requirements | A human, often with an agent drafting: goals, non-goals, acceptance criteria | Decides what, why and when |
| 1 | Plan | Coding agent, against the rules and documentation; one small vertical change | Leads larger architectural decisions |
| 2 | Branch | Coding agent in an isolated working copy with its own test data | — |
| 3 | Build | Coding agent: code, tests and documentation in one change | — |
| 4 | Continuous integration | Automated checks at commit, push and merge | Owns the rules the checks enforce |
| 5 | Code review | Review agents; every comment gets a fix or a written reason | Settles disputes and exceptions |
| 6 | Merge and test | Merge queue, then automated customer journeys on a production-like mirror | Decides on full test runs |
| 7 | Release | Automated release behind a deploy gate | Starts the release |
| 8 | Operate and maintain | Alerts start an agent that proposes a fix; scheduled agents hunt bugs, refactor and keep documentation current | Reviews proposals and prioritises |
Deep dive
Each workflow concept is shown as part of one operating model, so candidates and partners can understand how strategy, implementation, verification, and review connect.
The job is to shorten the path from product intent to verified change without removing accountability. Humans own priority, quality, and decisions.
Work is split across the same roles as in an ordinary team: plan, build, review, verify, and be on call. Each role uses the model that fits the task, cost, and risk.
The process describes roles and gates, not tools. We switch coding tool or model when a better one exists, without changing how work is reviewed and released.
Requirements carry testable acceptance criteria and explicit non-goals. An agent then knows when it is done, and a reviewer can see whether the change does what was intended.
Automated checks at commit, push and merge hold architecture, types, formatting and contracts. What must hold lives in gates, not in instructions.
Review agents read every change like a colleague. Every comment gets a fix or a written reason, and review has an end: if findings stop shrinking, we change approach.
Changes are proven in layers: tests, locked contracts, automated customer journeys in a production-like environment and, for visible changes, proof from a real browser.
A human releases to production after testing on a mirror of production. Monitoring alerts on errors, and an agent investigates and proposes a fix that a human reviews.
Scheduled agents hunt bugs, refactor and measure performance. Documentation points at the code it describes and is re-read when that code changes.
We measure lead time, cost per change, first-pass yield and change failure rate. Speed only counts if quality holds.
We do not claim this is the only correct way. It aligns with established practice for effective agents, human oversight, and continuous delivery — sources to read yourself:
Related pages in the product and platform story — with working links.
The deep dive below walks through the patterns, the gates, review, release and operations.
The product we build and the way we build it share a philosophy: trace what changed, learn from outcomes, and keep humans accountable for decisions that matter.
Deep dive
We build software like an ordinary, well-run engineering team: requirements, plan, branch, code and tests, continuous integration, code review, merge, testing in a production-like environment, release, monitoring and maintenance. The difference is that supervised AI agents do most of the work at every stage. Humans own priority, judgement and what reaches customers.
A loop, not a straight line. The human owns both ends: what gets built and what reaches production. A production error becomes a proposed fix that a human reviews.
Agents are not a helper on the side of engineering. They are how we build. Four commitments keep that accountable, whichever tools and models we use at the moment.
Humans set priority and architecture, own the exceptions and release to production. Agents plan, implement, verify and take the change all the way to the main branch.
Every coding agent reads the same rules and the same documentation and meets the same gates. Changing tool or model does not change the process.
Every important rule has a single implementation, and automated checks stop a second path around it. That way many agents do not build parallel truths.
Anything that affects operations needs a human. An agent responding to a production error leaves a proposed fix. It never releases on its own and never changes production.
Every stage is an established pattern from modern software engineering. What changes is who performs it. The gates get heavier the closer a change gets to production.
Checks and review send the change back until everything is resolved. The production release is started by a human.
We measure like any delivery team, with one addition for cost. Speed that brings more failures does not count as speed.
The time from a change being described to it landing on the main branch.
Model and compute cost per change that lands. Hard stages get stronger models, mechanical stages cheaper ones.
The share of changes that pass checks and review without another round.
How often a release needs a fix or a rollback.
Agents take over most of the writing. People move up: to priority, judgement and accountability for what reaches customers.
Decides what and when Sets goals, non-goals and acceptance criteria. Owns exceptions and decides on full test runs. Releases to production. 🤖
Builds and takes the change to main Plans against the rules and documentation and works in isolation. Writes code, tests and documentation in one change. Answers every review comment before the change lands. 🔍
Review like a colleague Read the whole change and look for defects. Specialised reviewers look at performance, security and architecture. Hold agent code and human code to the same bar. 🛠️
Owns the way of working itself Develops the gates, agent instructions and budgets per type of work. Chooses tools and models without the process having to change. Measured on lead time, cost per change, first-pass yield and change failure rate. 📡
Is on call Started by a serious alert from production. Investigates the cause and leaves a proposed fix. Never releases on its own and never changes production. 🗓️
Find work before anyone asks Hunt bugs and code smells on a fixed schedule. Review performance and how current the documentation is. Hand in findings as ordinary changes behind the same gates.
Many agents working at once need protection that does not depend on anyone remembering a rule. The coding agent sits inside mechanisms that can stop it.
Eight independent guardrails. None is enough alone. Together they let many agents work at once without harming the main branch or production.
A change to a core flow must describe what it affects, and a locked expectation cannot be edited next to the code it polices. "Update the test so it passes" gets caught.
Fixes are batched per review round. A finding can be answered with a written reason instead of another change. If findings stop shrinking, we change approach instead of patching on.
Files may not grow without bound, and new shortcuts past the type system are stopped. Code that is easy to read is easy to review, for humans and agents alike.
A release is exercised first in a production-like environment where no messages reach customers. Only then is it released to production.
Humans and agents use the same documentation. Automation, not good intentions, keeps it attached to the code.
An agent reads the rules, then only the documentation the task needs. Code decides how the system behaves; the documentation holds intent, vocabulary and architecture.
A page that describes code points at that code. When the code changes the page is flagged, and an agent re-reads it before the change lands.
A plan meant for an agent carries testable acceptance criteria and a clear scope. When the work is done, the plan leaves the queue in the same change.
Nothing here is unique. It is established delivery practice, applied consistently to agents.
Every agent has its own working copy, branch and test data. That is why many agents can work at once without overwriting each other's work.
UI, API, logic, tests and documentation move in one change. A change that can be tested end to end is easier for both agent and reviewer to judge.
Rules that must hold live in automated checks. Instructions give guidance; the gates make sure it is followed.
Humans hold the release and the exceptions. Agents do the rest, and what they do shows in change history, reviews and audit records.
| Pattern | Who performs it | The human's role |
|---|---|---|
| Requirements and priority | A human, often with an agent drafting | Decides what, why and in what order |
| Design and plan | Coding agent, against the rules and documentation | Leads larger architectural decisions |
| Feature branch | Coding agent in an isolated working copy with its own test data | — |
| Implementation and tests | Coding agent | — |
| Continuous integration | Automated checks at commit, push and merge | Owns the rules the checks enforce |
| Code review | Review agents, locally and on the pull request | Settles disputes and exceptions |
| Merge | Merge queue once checks are green and review is resolved | — |
| Production-like testing | Automated customer journeys on a mirror of production | Decides on full test runs |
| Release | Automated release behind a deploy gate | Starts the release |
| Monitoring and on-call | Alerts start an agent that investigates and proposes a fix | Reviews the proposal and decides |
| Maintenance and technical debt | Scheduled agents that hunt bugs, refactor and measure performance | Prioritises what they find |
| Documentation | Agents that keep the documentation in step with the code | Decides what is true |