Method
How we diagnose an operation, and what gets built on top of it when the diagnosis finds something worth building.
The order is the claim
Audit, then optimize, then automate. Understand how the work happens. Remove the waste from the process. Automate only what's left.
Reversing any two of those breaks it. The common failure is skipping straight to the third: you buy a tool, wire it to the process you already have, and now the broken version runs faster and costs a subscription. The second most common is skipping the first: redesigning a process from how the owner believes it works instead of how it really works, which produces a system the people doing the job route around.
Nothing about this sequence is ours. It is the closest thing to a settled result in this field. We've found the same three phases, in the same order, at three independent operators across four properties, one of them in recruiting, a vertical the others never touch. We're recording that, not claiming it.
What "audit" means concretely
A walkthrough, not a meeting. The person who does the work shows their screen, and every step gets captured without being fixed. Handoffs marked. Duplicate data entry marked. Manual time measured.
The single most useful question we ask: if your volume doubled next quarter, what would break first? Owners answer that one accurately far more often than they answer "where are your inefficiencies?"
Where we look first
The end of the pipeline, not the start. The research-heavy steps get automated first, because that is where the obvious wins are, and they keep improving. The last human action (send the message, make the call, submit the form) stays manual and becomes the whole bottleneck. We have watched a business with a fully automated research pipeline do every single piece of outreach by hand, one contact at a time.
Which is not what the assessment is. The assessment is an hour with you, and it gives us your account of how the business runs. That's enough to find where the money is going and rank what's worth fixing, and it's the right amount of work to do before anyone has committed to anything.
It is not enough to design a system on, because your version and your team's version will differ in exactly the places that decide whether the finished thing gets used. The walkthrough above is build work. It happens before anything gets architected, and we'd rather tell you now than have you find the gap later.
How the system gets built
If the audit finds something worth automating, this is what gets built underneath it. Six layers, bottom to top.
- 01
Clean data. The business’s own knowledge, structured and maintained as a source of truth instead of a folder of documents.
- 02
Tools. Small, specific actions the system can take: send the email, create the record, check the calendar.
- 03
Session. Context that carries between interactions, so nothing gets re-explained.
- 04
Skills. Your repeatable procedures, written down as fixed steps that run the same way every time.
- 05
Reasoning. The layer that interprets a request in plain language.
- 06
Harness. The management layer that keeps the other five running reliably.
Everything above layer one is worthless without layer one. This is the part most AI projects skip: they connect a language model to a pile of unstructured documents and get confident, fluent, unreliable answers. A knowledge base is the floor the rest of it stands on, which is why the audit comes first.
How each agent is scoped
Narrow, and deliberately constrained.
- Role: exactly what this agent owns, and what it is forbidden to do. "You are my assistant" is too vague, and a vague role is why most of these freelance and get switched off.
- Skills: the specific procedures it runs, each with a fixed stopping point and explicit conditions for when not to act. Knowing when to do nothing is most of what makes an assistant trustworthy.
- Routines: when it runs without being asked.
Three rules we hold to, and you should hold us to.
It drafts. It doesn't send.
Nothing goes to a customer without a person approving it. This is the rule that gets tempting to relax once the drafts are consistently good. We don't relax it.
It never invents a link, a price, or a number.
It reuses what already exists or it says it doesn't have it.
It stays quiet when there's nothing to say.
A system that reports "no updates" every morning trains you to ignore it, and then you ignore the morning it matters.
Where we don't use AI at all
Plenty of the work does not need it. If a task follows a rule every time — this field goes there, this number over that threshold gets flagged, this document type goes to this person — then a plain automation does it faster, cheaper, and without ever being creative at the wrong moment. Some of the most valuable things we build contain no AI whatever.
The split we work to: rules for deterministic work, an agent for judgment work, and a person for decisions — with the system preparing the decision rather than making it. Getting that classification right is most of what keeps a build small.
That is a fair objection and we would not argue with it. Nothing we build has to touch anything your customers see. The quoting, the scheduling, the paperwork, the chasing — none of that carries the risk she is describing, and it is where the hours are anyway.