Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is free and source-available on Github. Star git-lrc to help devs discover the project. Do give it a try and share your feedback.
Yesterday we landed on a definition: an agent is a system that independently completes a task on your behalf, built from three pieces (a model, tools, and instructions).
Now the fun question.
Once you have one agent, how do you get it to actually do things in a loop? And when does it make sense to split the work across several agents instead of one?
The run loop
Every agent needs the concept of a "run."
It is usually a loop: the model runs, maybe calls a tool, looks at the result, and runs again, until some exit condition is reached.
Common exit conditions are a final structured output, an error, or hitting a max number of turns.
This while-loop is the heartbeat of every agent.
It is true for a single agent, and it is true for a network of them.
The only thing that changes in bigger systems is who gets to run on each turn.
Start with one agent
Here is the advice that saves people the most pain: max out a single agent before you reach for many.
A single agent handles more than you would expect.
Need a new capability? Add a tool.
Each tool widens what the agent can do without forcing you to coordinate multiple models, manage handoffs, or debug who-did-what.
One agent, one loop, a growing toolbox.
This keeps evaluation and maintenance simple, which matters a lot more than it sounds when you are debugging at 11pm.
A neat trick for managing complexity without splitting: use a prompt template with variables instead of a pile of separate prompts.
"""You are a call center agent for {{company}}. You are talking to
{{user_name}}, a member for {{tenure}}. Greet them, thank them for
being a loyal customer, and help with their question."""
New use case? Update the variables, not the whole workflow.
When to split into multiple agents
You split when a single agent starts to buckle.
Two symptoms to watch for:
- Complex logic. The prompt is turning into a maze of if-this-then-that branches and is getting hard to scale. Each logical branch is a candidate for its own agent.
- Tool overload. The problem is rarely the raw count of tools, it is overlap. Some agents happily juggle 15-plus well-defined tools; others get confused by fewer than 10 that look alike. If clearer names, parameters, and descriptions stop helping, split.
When you do split, there are two patterns worth knowing.
Pattern 1: the manager
One central agent (the "manager") coordinates specialists by calling them as tools.
The specialists do their thing and return results.
The manager stays in control and stitches everything together into one reply.
This fits any time you want a single agent holding the thread with the user.
In code, the specialists are literally passed in as tools:
manager_agent = Agent(
name="manager_agent",
instructions="You are a translation agent. Use the tools given "
"to you to translate. If asked for multiple "
"translations, call the relevant tools.",
tools=[
spanish_agent.as_tool(tool_name="translate_to_spanish",
tool_description="Translate to Spanish"),
french_agent.as_tool(tool_name="translate_to_french",
tool_description="Translate to French"),
italian_agent.as_tool(tool_name="translate_to_italian",
tool_description="Translate to Italian"),
],
)
Pattern 2: decentralized handoffs
Here there is no boss.
Agents are peers, and one can hand off the whole conversation to another.
A handoff is a one-way transfer: the new agent takes over execution and the current state, and the original agent steps out.
This is perfect for triage.
A first agent figures out what the user wants, then passes them to the right specialist.
The triage agent reads the question, recognizes it is about an order, and hands off to the order management agent, which replies directly to the user.
triage_agent = Agent(
name="Triage Agent",
instructions="You are the first point of contact. Assess the "
"customer's request and route it to the right "
"specialized agent.",
handoffs=[technical_support_agent, sales_assistant_agent,
order_management_agent],
)
Manager vs handoff, quickly
Use the manager when you want one voice talking to the user and combining results.
Use handoffs when you are happy to let a specialist fully take the wheel.
Whichever you pick, the same rule holds: keep components flexible, composable, and driven by clear prompts.
What's next
You can now run a single agent in a loop, and you know the two ways to scale to many when one is not enough.
There is one piece left, and it is the one that decides whether your agent is safe to put in front of real users: guardrails.
In part 3 lets look at layered defenses, prompt injection, PII, and knowing when to pull a human into the loop.
Disclaimer: This article was written by me; AI was used to fix grammar and improve readability.
AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs โ without telling you. You often find out in production.
git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.
Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.
โญ Star it on GitHub:
HexmosTech
/
git-lrc
Free, Micro AI Code Reviews That Run on Git Commit
| ๐ฉ๐ฐ Dansk | ๐ช๐ธ Espaรฑol | ๐ฎ๐ท Farsi | ๐ซ๐ฎ Suomi | ๐ฏ๐ต ๆฅๆฌ่ช | ๐ณ๐ด Norsk | ๐ต๐น Portuguรชs | ๐ท๐บ ะ ัััะบะธะน | ๐ฆ๐ฑ Shqip | ๐จ๐ณ ไธญๆ | ๐ฎ๐ณ เคนเคฟเคจเฅเคฆเฅ |
git-lrc
Free, Micro AI Code Reviews That Run on Commit
ย 
ย 
ย 
ย 
GenAI today is a race car without brakes. It accelerates fast -- you describe something, and large blocks of code appear instantly. But AI agents silently break things: they remove logic, relax constraints, introduce expensive cloud calls, leak credentials, and change behavior -- without telling you. You often find out in production.
git-lrc is your braking system. It hooks into git commit and runs an AI review on every diff before it lands. 60-second setup. Completely free.
In short, git-lrc helps Prevent Outages, Breaches, and Technical Debt Before They Happen
At a glance: 10 risk categories ยท 100+ failure patterns tracked ยท every commitโฆ
Top comments (12)
Love the banner ๐
Thanks a lot bud <3
What happens after a one-way handoff goes a little fuzzy for me. Once the triage agent passes the whole conversation to the order agent, what does the user do when their next message is actually a billing question? With the manager pattern the boss keeps the thread so that case is easy, but with peer handoffs it feels like you either give every specialist a "send it back to triage" escape hatch or you accept that one wrong route strands the user. Curious how you've seen the return trip handled, or whether you just design so handoffs are rare.
The "max out one agent first" advice matches what I keep relearning. Every time I split too early, the cost showed up not in the agents themselves but in the handoffs, where context quietly dropped between turns and nobody owned the failure. I now only reach for a second agent when one tool set genuinely fights another for the same context window.
I see
The "max out one agent before splitting" advice is underrated. I see too many teams jump straight to multi-agent architectures because the diagrams look impressive, then spend weeks debugging handoff logic that a single agent with well-scoped tools would have handled fine.
Your point about tool overlap being the real breaking point resonates. I have dealt with agents that had 8 tools where 3 of them did similar things with slightly different APIs. The model would pick the wrong one half the time. Splitting by tool domain solved it instantly.
One thing I'd add: the memory question cuts across both patterns. Whether you run one agent or five, they all need to persist context between turns. I have been experimenting with embedded storage for agent state (working on moteDB for this exact reason), and the tradeoff is the same either way. You either keep everything in memory and lose it on restart, or you add a persistence layer and deal with the latency tax.
What is your take on agents that need to share intermediate state? Do you pipe outputs between them directly, or use a shared store that each agent reads from?
Another killer breakdown, brooh!
The advice to "max out a single agent before reaching for many" is a massive lifesaver. Itโs so easy to fall into the trap of over-engineering a massive multi-agent mesh network for something that really just needed a couple of extra tools and a cleaner prompt template. "Debugging at 11pm" is a feeling way too many devs know too well!
Your explanation of the Manager pattern vs. Decentralized Handoffs is incredibly clear. Passing a specialist agent as a tool to the manager is such an elegant design pattern that doesn't get explained simply enough in most documentation.
Thatโs usually where things get really messy in production. Keep up the great work with this series and git-lrc!
Thanks G :)
The orchestration question gets harder when agents need persistent memory. If one agent runs and forgets, you end up re-explaining context every loop. If you split across many agents, how do they share state without creating a coordination mess?
We hit this with moteDB -- an embedded multimodal DB designed for embodied AI scenarios. The core insight was that agents need structured memory that survives the session, not just rolling context windows.
Single-agent with memory, or multi-agent with shared state -- which pattern are you finding works better in practice? The coordination overhead of many agents seems like it could eat the productivity gains.
The one-agent-or-many question usually gets answered backwards, teams reach for many because it looks sophisticated, then drown in coordination overhead. The honest default is the fewest agents that can do the job with clear, checkable handoffs. Multi-agent only pays off when each agent has a tight, verifiable boundary; otherwise you've built a system harder to reason about than the monolith it replaced. Orchestration without enforced contracts between agents is just distributed confusion.
This made me thinkโat what point do you decide it's time to split one agent into multiple specialized agents? Is there a clear rule of thumb?
Some comments may only be visible to logged-in visitors. Sign in to view all comments.