Services — Path 02 — AI Engineering
The prototype answered the clean examples beautifully. Then it met a missing field, a contradictory source, an unusual request, a permissions review, an existing system nobody wanted to replace, and a person who needed to know why the answer was safe to use before signing her name to it. None of this means the idea was wrong. It means the idea had only been introduced to the easy part of your company.
A useful AI system has to survive a normal Tuesday.
01
— The tools it can use, and the actions it is allowed to take.
— The moments that require a person, without exception.
— The release path, and the way back.
A stronger model resolves none of these. It cannot clarify authority that was never granted, find sources that do not exist, make an invisible failure visible, or adopt a workflow nobody owns. That surrounding structure is the actual engineering, and it is where a decade of building these systems, through several hype cycles and their hangovers, earns its keep.
02
The form follows the decision. The work can include:
The workflow determines the system. The agent type comes later.
03
If an important rule lives only in someone's head, the system cannot follow it, and neither can the next person who joins. So we write the rules down where the machine and the humans both encounter them: which sources are authoritative, what may be changed, what is forbidden, what requires approval, when to stop instead of guessing. The rules live beside the code, not in a policy document nobody opens.
A chat thread is a poor place for a company's reasoning to live. So the work gets version control, decision records, and a history a person or an agent can inspect. What changed and why stays recoverable. A new working session, human or machine, starts from the current state of the world instead of from whoever remembers the last conversation. It sounds unglamorous. It is the difference between a system and a séance.
04
AI has made it wonderfully easy to produce something that looks finished, which means the honest work has moved one step later: knowing whether it is safe to depend on. We hold those apart as two different states. Review-ready means the intended behavior is visible and a knowledgeable person can examine it. Launch-ready means the permissions, sources, approval rules, integrations, claims, edge cases, monitoring, and recovery path have each been checked by the person responsible for them. Convincing is a feeling. Ready is a checklist. We ship on the second one.
05
The useful examples are rarely the pristine ones in the kickoff deck. We need the strange request, the incomplete record, the disagreement between systems, and the output an experienced operator rejects on sight but struggles to explain. Those examples shape the instructions, the tests, the interface, and the escalation path, and the people who supplied them stop being bystanders to the system. They become its owners, which was the plan all along.
Depending on the risk: a private environment, an explicit human gate on anything that touches customers, money, or data, checks tied to the real workflow, and a known-good state that can be restored without heroics. Controls do not make mistakes impossible. They make mistakes survivable, and they make the boundary between an experiment and the business impossible to cross by accident.
06
The software works against real examples, in the workflow where it will live. Its authority is bounded. Anything that reaches customers, money, or data can be reviewed. Its behavior is observable, and its releases can be recovered. And, just as deliberately, the people who own the workflow can brief the system, judge its output, escalate the right exceptions, and make a bounded next change without calling us. Done, in other words, describes your team as much as the software. When we leave, it is all yours: the code, the standards, and the ability to keep going.
07
The decision and its owner are already clear. A prototype needs to become dependable. An existing workflow needs a senior builder who can work across product, software, and operations. You want your team to understand and direct what happens next.
Undirected staff augmentation, a request to ship an unbounded autonomous system, or a build whose business owner will not participate.
Not sure the decision is settled? Start with Strategy →Tell us what it can do, where it breaks, and who needs to trust it. That is enough to begin.