It is very easy to look at a set of AI assistants and feel like you have built a system.
One assistant answers new enquiries. Another handles follow-up. Another qualifies a lead. Another books a call. They all exist in the platform. They all have names. They all have prompts. They all look like part of the same operation.
But that is not the same thing as a working business system.
That was the practical lesson inside the Vapi squad build.
Vapi is a voice AI platform. In this case, the work involved several voice assistants that needed to be managed together. Each assistant had its own instructions, opening message, tools, and deployment settings.
At first glance, the natural business instinct is to think in terms of the group.
Get all the assistants deployed. Make the squad visible. Move quickly. If the assistants are live, surely the system is close.
But the moment you ask a simple question, the weakness appears.
Where does this assistant's behavior actually come from?
That question matters more than it may seem.
If an AI assistant speaks to a customer, qualifies a lead, books a meeting, or passes work to another assistant, the business owner needs to know why it behaved the way it did.
Was that greeting written in the source files?
Was that tool deliberately attached?
Was that instruction reviewed?
Or did the assistant inherit something from a previous live version inside the platform?
That difference is not technical trivia. It is operational control.
A business system should not depend on hidden behavior that nobody can easily explain. If an assistant is allowed to say something, use a tool, or make a handoff, that permission should come from a place the operator can inspect.
A simple example would be a stale booking tool.
Suppose the source-owned configuration for the sales assistant says its job is to qualify the caller and then hand the caller to a booking assistant. That is the behavior the business thinks it has approved.
But inside the live Vapi dashboard, the sales assistant may still have an old calendar or `book_call` tool attached from a previous version.
Now a caller says, "Can you book me in for Tuesday?" The sales assistant books the meeting directly instead of handing the caller to the booking assistant.
From the outside, it looks like the assistant ignored the process. But the real issue is more specific: the live platform still gave that assistant permission to book meetings, even though the visible source configuration said it should only qualify and hand off.
That is hidden behavior. The team may waste time rewriting the prompt or inspecting the handoff rules, when the actual problem is a stale tool attachment in the platform.]]]
The reset was to stop treating the squad as the first unit of control.
The assistant had to become the first unit of control.
Each assistant needed its own source-owned configuration. In plain language, that means the business should be able to point to a file and say: this is what this assistant is supposed to be, this is what it is allowed to do, this is what it says first, and these are the tools it can use.
That gives you a much cleaner way to manage the system.
If the sales assistant behaves badly, you inspect the sales assistant. If the support assistant uses the wrong tool, you inspect the support assistant. If the booking assistant opens the call with the wrong message, you inspect the booking assistant.
You are not trying to untangle a vague group of agents. You are looking at one controlled business role.
That is the first layer.
Every assistant must be understandable on its own.
But there is a second layer that is just as important.
A set of understandable assistants is still not a coordinated system.
It is only a set of parts.
For a business owner, this is the difference between hiring several people and designing the workflow between them.
You may have a receptionist, a salesperson, a support person, and an account manager. But the business only works properly when everyone knows where their responsibility starts, where it ends, and when the customer should be passed to someone else.
AI assistants are no different.
The handoff rules matter.
When should the first assistant pass the caller to the next one?
What information should be carried forward?
What should never be handed off?
What happens if the customer asks for something outside the assistant's role?
What should the business inspect if the caller ends up with the wrong assistant?
Those are system questions, not assistant questions.
This is where many AI projects become confusing. People say they have multiple agents, but they have not designed the operating model between them.
The result is a fragile system that looks impressive in a demo and becomes difficult to trust in real use.
If something goes wrong, nobody knows where to look.
Was the individual assistant poorly instructed?
Was it allowed to use the wrong tool?
Was the handoff missing?
Was the squad configuration wrong?
Was the system relying on an old setting from the platform?
When those questions are mixed together, debugging becomes expensive. Not always in software cost, but in attention, confidence, and time.
The better model is simple.
First, control each assistant individually.
Second, design the handoffs between them explicitly.
Third, test the whole flow as a business process, not just as a collection of AI parts.
This is the part I think matters most for non-technical business owners.
The value is not in being able to say, "we have multiple AI agents."
The value is in being able to say:
We know what each assistant is responsible for.
We know what each assistant is allowed to do.
We know when one assistant should pass work to another.
We know where the instructions live.
We know what to check when something fails.
That is a very different level of ownership.
It also changes how you should evaluate AI work inside your business.
Do not only ask whether the assistant exists.
Ask whether its behavior is controlled.
Do not only ask whether several agents are deployed.
Ask whether the handoffs are designed.
Do not only ask whether the demo worked.
Ask whether the system can be inspected when it does not.
This is where practical AI becomes less magical and more useful.
A business does not need a pile of clever assistants. It needs a clear operating system.
Each assistant should have a job. Each job should have boundaries. Each boundary should be visible. Each handoff should be deliberate.
That is the lesson from the Vapi squad build.
A squad is not created by deploying several assistants.
A squad is created when those assistants are individually controlled and then connected through tested rules that make sense for the business.
The extra structure may feel slower at the start. But it saves you from a much bigger problem later: not knowing whether you are dealing with a bad assistant, a bad handoff, or a hidden setting nobody meant to rely on.
For a business owner, that clarity is the real asset.
It is the difference between having AI tools scattered around the business and having an AI system you can actually run.
-----------
If you find this content useful, please share it with this link: [https://patrickmichael.co.za/subscribe](https://patrickmichael.co.za/subscribe)