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 (1)
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.