Chapter 5 of 7, 9 min read
Run it with an engineer on your team
Systems break on real data. Someone has to watch, fix and extend them. What that person does and how to get one.
The first system works. The second works too. By the fifth, something breaks on a Tuesday and nobody knows why.
AI systems meet bad data, a dead API, a changed form. Somebody has to own them the way someone owns the website. That person is an engineer who works inside your team, learns how the work gets done, and keeps the systems current.
What the person does
- Keeps the company brain current as processes change.
- Watches every system, with a log of each prompt, tool call and error, so you can see what happened.
- Builds the next system from your hour-leak sheet.
- Shows the work at the end of each day.
The loop they follow is the one from our forward-deployed engineer roadmap: audit how the work really happens, build against it, measure, and deploy. They repeat it for each system. The difference from a consultant is that they write the code and stay for the result.
A normal day
| Time | What happens | Who |
|---|---|---|
| Morning | Read the overnight log. Check which outputs were flagged NEEDS HUMAN. | Engineer |
| Late morning | Review the day's outputs. Mark right, wrong, unclear. | Reviewer on your side |
| Afternoon | Fix the brain files behind each "wrong". Build the next system. | Engineer |
| End of day | Short walkthrough of what changed and what is next. | Engineer and reviewer |
“Fantastic and quite hassle-free. Watch the end-of-day review, give a couple of points of feedback, and it would be fixed the next day.”
Your options
| Option | Good when | Watch out for |
|---|---|---|
| A person on your team learns it | You have a curious operator with spare time | It becomes a side project and stalls |
| You hire an engineer | You can wait through a hiring round | Weeks of search before day one |
| An AY engineer joins your team | You want systems running while you hire or instead of hiring | You still need a reviewer and an owner on your side |
How to brief one
Hand over the brain folder, the hour-leak sheet and a list of the tools involved. Name one owner on your side who reviews. Agree the daily review before day one. A good brief lets the engineer start building on the first day.
# Brief for the engineer
## Build list (from the hour-leak sheet)
1. Invoice matching, 6.0 h/week, brain/processes/invoice-matching.md
Tools: ERP, finance inbox
2. Support first reply, 9.0 h/week, brain/processes/support-first-reply.md
Tools: helpdesk, help docs
3. Monday report, 3.5 h/week, brain/processes/monday-report.md
Tools: CRM, billing
## Reviewer
Dana for 1. Mo for 2 and 3. Daily check at 16:30.
## Working means
System 1 matches 9 of 10 of last week's invoices and
Dana's review takes under five minutes.
## Access
Read-only on the ERP and helpdesk to start.Exercise
Write the one-page brief
- 1Paste your top three tasks from the hour-leak sheet at the top of a page.
- 2Under each, link the brain file and list the tools it touches.
- 3Name the reviewer on your side and the time of the daily check.
- 4Write the one sentence that says what "working" means for the first system.
- 5List the access the engineer needs on day one, read-only wherever you can.
You end with. One page you can hand to an engineer, yours or ours, on day one.
Stuck on this chapter? Talk to an engineer. 30 minutes, you keep the notes either way.