Building an In-House AI Team

Companies hear "multi-agent system" and picture something complicated. In practice the idea is simple: instead of one AI doing everything, several AI agents each handle one part, and something coordinates them.

The hard part is not the technology. It is deciding who does what — the same problem you face when building a team of people.

This article covers how to build an in-house AI team, what to decide before you build, and where these systems fail.

The Problem With One Agent Doing Everything

Most companies start with a single prompt that tries to do the whole job. Read the data, analyse it, write the report, check the numbers. It works on small tasks and degrades on large ones.

The degradation is not random. When one agent handles many steps, each step competes for attention with the others. Instructions given at the start get less weight by the end.

There is a second cost that shows up later. When the output is wrong, you cannot tell which step failed. You rewrite the whole prompt and hope. That is expensive and it does not accumulate into anything.

Related: How Multi-Agent AI Helps Philippine Small Businesses Handle Complex Workflows explains this in detail.

Why Adding More Prompts Does Not Fix It

The middle row is where most companies get stuck. They split the work into three or four prompts, then a staff member runs them in order and copies output between them.

This is better than one prompt, and it makes a person the bottleneck. It also reintroduces copying errors, which was one of the reasons to automate in the first place.

A multi-agent system means the handoffs are defined, not manual. Agent A's output is Agent B's input, by design.

Related: When Multi-Agent AI Is the Wrong Choice: Five Situations Where One Agent Beats Five explains this in detail.

What a Working Setup Looks Like

Notice the right-hand column. Defining what each agent must not do matters as much as defining its job. Without that boundary, agents drift into each other's work and you lose the ability to locate a failure.

This is the same principle as running a team of people. In my own experience managing development teams in the Philippines, I check the team's status at 7 in the morning, meet the technical lead at 8, review development progress and handle specification changes through the morning, do quality management and prepare client reports in the afternoon, and assign the next day's tasks in the evening. Setting priorities by time slot, and batching heavy processing overnight, is what keeps the service running without stopping.

That structure exists because roles and handoff points are fixed. An AI team needs the same thing, for the same reason.

Four Steps to Build One

Step 1: Write down the steps a person currently performs (half a day)

List every step, including the copying. Do not design agents before this. If you skip it, you will build agents for the wrong steps.

Step 2: Decide the boundary for each step (1 day)

For each step, write what it produces and what it must not touch. This becomes the agent's instruction. Vague boundaries produce agents that overlap.

Be specific in the way you would be with a person. Telling staff "sometime this week" produces different results than "by 3pm Friday." I use the specific form with our team here in the Philippines, and it works the same way with agents. Specific inputs, specific outputs, specific limits.

Step 3: Connect two agents first (2 to 3 days)

Do not build all four at once. Connect the collector and the analyst, run it for a week, and check the handoff. Most problems appear at the boundary, not inside an agent.

Step 4: Add the reviewer last (ongoing)

The reviewer checks the numbers against the source. Add this once the earlier steps are stable, because a reviewer checking unstable output produces noise.

Never remove the human approval at the end. The reviewer catches number errors. It does not decide what is appropriate to publish.

Related: How Multi-Agent AI Systems Help Philippine SMEs Automate Complex Work explains this in detail.

What to Measure, and What It Costs

The third row deserves attention. Several agents means several calls, so a multi-agent run costs more per execution than one prompt. The saving comes from fewer reruns and less human time, not from lower call costs.

If the task is small and works fine as one prompt, splitting it into agents makes it more expensive for no benefit. Use this pattern when a single prompt is already failing.

Also track which step failed. Before separating roles, you could not answer that question. After separating them, you can — and that is often worth more than the speed gain, because it turns a rewrite into a targeted fix.

FAQ

Q: How many agents should we start with?

A: Two. Connect one collecting step to one analysing step and run it for a week. Most companies that start with four or five spend their time debugging the coordination rather than the work. Add agents once the first handoff is reliable.

Q: Do we need engineers for this?

A: For a first version connecting two steps, someone comfortable with tools and settings can do it. Bring in engineering when you connect several internal systems or handle customer data, because errors there are expensive to undo.

Q: What should never be handed to an agent?

A: Deciding what is true enough to publish, and deciding what is appropriate for a customer to see. Agents can check numbers against a source. They should not be the last step before something leaves your company.

Q: Will this work with local staff running it?

A: Only if you build it that way. In a Philippine subsidiary the people running the system daily are local staff, so the instructions and the procedures need to work in English and be editable without the original builder. Design for that from the start rather than retrofitting it.

Q: How long before it is stable?

A: Two to four weeks for the first two agents, and one to two months before the output is reliable enough to reduce review time. The first weeks usually expose problems in the data sources rather than in the agents.

Start by Naming the Boundaries

A multi-agent system is a team. The technology question is smaller than the organisational one: who does what, what each part must not touch, and where the handoffs sit.

Write down the steps a person performs today. Define the boundary for each. Connect two agents and run them for a week. Add the rest only when the first handoff holds.

Note that tools, model names and pricing change quickly. This article reflects the situation as of August 2026. Check current documentation before committing to a specific setup.

References

• Anthropic (developer of Claude and Claude Code; official product and documentation information)
• Anthropic Newsroom (official announcements on agent capabilities and enterprise features)
• OpenAI (official product information and enterprise documentation)