You Can Build Your Own AI Agents Team, But Will You Own What Happens Next?

Follow a client proposal through the work of coordinating agents, checking progress and improving results, then decide what your firm wants to build and run

Imagine watching an AI demo turn a new client enquiry into a proposal using your studio’s past work. You can see where it would help, and someone on your team is keen to try building it.

That could be a sensible decision. A ready-made tool may cover the job, or a capable colleague may be able to connect what’s missing.

Bringing in help should earn its place too. The useful comparison is what each route lets your firm accomplish, and how much work your people take on to keep it running.

For the owner, a proposal still needs commercial judgement. The attraction is reducing the work around the craft, so the relevant material arrives ready to review.

Follow the proposal through the firm

Consider a hypothetical studio workflow, starting with a new enquiry and a current brief. One agent finds relevant past projects and another uses that material to prepare a proposal for the owner’s review.

Before drafting starts, think of the handoff as the package one agent passes to the next. It needs to include the brief, source documents and unanswered questions, while distinguishing the client’s requirements from ideas borrowed from earlier work.

That handoff is a design decision, as is how many AI agents the work needs. If one can research and draft well with the same information and permissions, splitting those jobs may just add another exchange to manage.

And with several agents involved, that coordination is often called multi-agent orchestration. In this proposal workflow, it covers who does what, how the work passes between agents, what happens if information is missing and when the owner needs to review the result.

So those steps and alternative routes can be represented as a graph. Designing that structure, including the information that travels through it, also often called graph engineering.

Alongside the handoffs, the studio needs a way to see progress. Its authorised team should be able to open the proposal task and find the latest draft, supporting sources and a clear status, such as waiting for a pricing decision.

And the communication channel should bring that decision to its owner, with enough context to answer. A task record should also capture model and tool spending, including repeat attempts, so the team can inspect what completing the proposal consumed.

So, when we use the term Agentic OS, we mean this wider arrangement around a firm’s work. Existing platforms already provide orchestration and activity tracking, along with human approval mechanisms that pause selected actions until a person reviews them.

The firm-specific work is choosing and connecting those capabilities so this proposal reaches the right person in a usable state.

“The handoff carries the brief, sources and open questions; the team can inspect progress and spending alongside the work”

When the work needs a decision

Now suppose a past proposal contains a rate that differs from the studio’s current pricing record, and the instructions do not say which applies. The workflow needs a route for that ambiguity.

In this design, both sources go beside the draft for the pricing owner to decide. The task stays visibly waiting until the approved rate comes back, with the decision attached.

“Both sources reach one pricing owner. The decision stays visible while pending, then travels back with the approved rate”

The owner still judges the price and scope. But the question arrives with its evidence, and the rest of the team can see that it already has someone’s attention.

In a hypothetical law-firm workflow, an unresolved client instruction could take a similar route to the responsible lawyer. Preparing the material and making the professional decision are separate responsibilities.

If the handoff leaves that preparation to you, you can end up repeatedly supplying context, restarting work and chasing answers. And this refers to “bot-sitting”, which describes the effort of making AI output usable, including checking and correcting it.

Some of that review is valuable. What deserves attention is the avoidable work around it, such as answering the same request again because another agent cannot see the pending decision.

Nicholas (Aikin's founder) encountered that problem while building Aikin’s own system. In Making Lemonade, he describes repeated requests for the same approval and the resulting rule: one owner per decision, with no repeat escalation while it is pending.

Improve the next run

Once the pricing decision is resolved, look at why it was needed. If old rates keep finding their way into drafts, correcting each proposal leaves the recurring cause in place.

So the studio needs to agree which pricing source takes precedence and build that rule into the handoff. Send the current record with the past example, while keeping a review route for missing information or a client-specific exception.

Then test the change against ordinary enquiries and cases with missing or contradictory information. Check that the draft uses the right rate, preserves the agreed scope and still asks for help when it should.

Aikin’s internal build log records a smaller improvement with a similar purpose. One scheduled digest, an automatically generated summary, was changed to create follow-up tasks only when there was something to follow up, rather than adding a task after every run.

That is a useful question for the studio’s builder too: which follow-ups need action, and which exist only because an agent ran?

“Agree the source rule, update the handoff and test the change against ordinary and exception cases. Compare quality and completion alongside time and cost”

To assess the change, compare completed proposals before and after it, including corrections and the time people spend coordinating them. A shorter approval queue means little if people have simply stopped checking the work.

Keep the costs separate too: model and tool usage, implementation and support fees, and the team’s own time. A cheap generation followed by repeated corrections can be a poor trade for an owner whose attention is already stretched.

So judge the system by usable work completed, its quality and what it asks of your people. Here, tuning means adjusting how the system works, perhaps by changing an agent’s instructions, combining roles or replacing a step with a straightforward automation.

Those choices are part of the build, and someone needs to keep making them as the firm’s work changes.

Who will run the system?

“Choose a delivery route by its fit and the work your firm will still own. All three can use the same underlying platform”

These routes can share the same underlying platform. An outside builder might configure existing tools, while an internal team might buy most of what it needs and build only the missing connection.

For the studio, try the existing tool on the proposal workflow first. If it handles the required sources, review and handoffs well, and the team can operate it, there may be little reason to commission a larger system.

And if a colleague can build the missing pieces, give that work an explicit owner and time allocation. Those hours need a place in the workload alongside client delivery, including after launch.

Outside help deserves the same scrutiny. Ask which recurring tasks the partner takes on, which remain with the studio and what happens when a source document, integration or business rule changes.

Buying technical help also leaves commercial decisions with the firm: in this example, the studio decides what scope and price it will offer. Technical maintenance can sit with a colleague or provider under an agreed arrangement.

The question is whether that arrangement gives the owner time back after coordination, review, corrections and upkeep are counted, while keeping the work good enough for clients.

What experienced help should leave behind

Aikin’s approach is to build alongside the people doing the work: map the process, connect the necessary tools and make agent activity and costs visible. The delivery model includes a handover the team can operate, with continued support available if wanted.

Experience should be visible in the decisions a builder can explain. For this proposal, that means why the agents are separated, how they use current sources and what changed after testing exposed repeat work.

It also means explaining how future changes will be tested. A new model or integration still has to work with the firm’s existing workflow.

So take a recent piece of client work to the person you are considering building with. Ask them to walk it through their proposed system, including a missing fact or conflicting instruction, and show what your people would need to do.

For the studio owner, the goal is a proposal ready for judgement, with its sources and unresolved decisions close at hand. Assess the proposed system by how convincingly it gets there and who will keep it working.

If you want help working through that choice, bring a workflow like this to Aikin.

~ From Nicholas O'Neill and the Aikin team

FAQ

Where should a firm start with an AI team?

Start with one recurring workflow, such as preparing a proposal, and agree what a usable result looks like. Then try an existing tool against that requirement before deciding what needs to be built.

Does every task need its own AI agent?

No. If one agent can handle the work well with the same context and permissions, another agent may add an unnecessary handoff.

So separate responsibilities when there is a practical reason, then test whether the split improves the result.

How can you tell whether AI is saving time or creating bot-sitting?

Compare similar completed jobs, counting the time spent preparing inputs, coordinating agents, reviewing results and correcting mistakes. Keep quality in the comparison too: removing a useful review step does not establish that the system is better.

What should you ask for before an AI system is handed over?

Ask for a walkthrough of the work your team will operate, including a missing fact or failed step. Then agree who handles changes and support, what that support covers and which decisions remain with your firm.

Sources

• Multiagent orchestration documentation: delegation, activity tracking and agent communication.

• Human-in-the-loop for AI tool calls: approval before selected tools execute.

• 3 Years of Graph Engineering with LangGraph: workflow steps, routes and shared state.

• Work AI Index: the meaning of bot-sitting.

• Making Lemonade: Nicholas’s account of repeated approval requests and the rule introduced to handle them.

• How Many AI Agents Do You Actually Need?: deciding when work needs a separate agent.

• Most of your senior people's time isn't design: the work around the craft.

• Aikin’s Agentic OS approach: workflow design, delivery alongside the client and optional ongoing support.