{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicarsw6uwdvyesxcv54uwvnhlyort35dtvfbtg24gkyou2gf2zbki",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3mp4ykg74dcf2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreia734ipyzfqyxhghld7tb4mghlxazy5zk53lxyzg2jpk5jpteh5ea"
    },
    "mimeType": "image/webp",
    "size": 104468
  },
  "path": "/lovestaco/one-agent-or-many-orchestrating-ai-agents-without-the-mess-1g1l",
  "publishedAt": "2026-06-25T17:44:06.000Z",
  "site": "https://dev.to",
  "tags": [
    "ai",
    "programming",
    "webdev",
    "beginners",
    "Star git-lrc",
    "HexmosTech",
    "git-lrc",
    "🇩🇰 Dansk",
    "🇪🇸 Español",
    "🇮🇷 Farsi",
    "🇫🇮 Suomi",
    "🇯🇵 日本語",
    "🇳🇴 Norsk",
    "🇵🇹 Português",
    "🇷🇺 Русский",
    "🇦🇱 Shqip",
    "🇨🇳 中文",
    "🇮🇳 हिन्दी",
    "10 risk categories",
    "100+ failure patterns tracked",
    "View on GitHub"
  ],
  "textContent": "_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._\n\nYesterday 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).\n\nNow the fun question.\n\nOnce 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?\n\n##  The run loop\n\nEvery agent needs the concept of a \"run.\"\n\nIt is usually a loop: the model runs, maybe calls a tool, looks at the result, and runs again, until some exit condition is reached.\n\nCommon exit conditions are a final structured output, an error, or hitting a max number of turns.\n\nThis while-loop is the heartbeat of every agent.\n\nIt is true for a single agent, and it is true for a network of them.\n\nThe only thing that changes in bigger systems is _who_ gets to run on each turn.\n\n##  Start with one agent\n\nHere is the advice that saves people the most pain: **max out a single agent before you reach for many.**\n\nA single agent handles more than you would expect.\n\nNeed a new capability? Add a tool.\n\nEach tool widens what the agent can do without forcing you to coordinate multiple models, manage handoffs, or debug who-did-what.\n\nOne agent, one loop, a growing toolbox.\n\nThis keeps evaluation and maintenance simple, which matters a lot more than it sounds when you are debugging at 11pm.\n\nA neat trick for managing complexity without splitting: use a prompt template with variables instead of a pile of separate prompts.\n\n\n\n    \"\"\"You are a call center agent for {{company}}. You are talking to\n    {{user_name}}, a member for {{tenure}}. Greet them, thank them for\n    being a loyal customer, and help with their question.\"\"\"\n\n\nNew use case? Update the variables, not the whole workflow.\n\n##  When to split into multiple agents\n\nYou split when a single agent starts to buckle.\n\nTwo symptoms to watch for:\n\n  * **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.\n  * **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.\n\n\n\nWhen you do split, there are two patterns worth knowing.\n\n##  Pattern 1: the manager\n\nOne central agent (the \"manager\") coordinates specialists by calling them _as tools_.\n\nThe specialists do their thing and return results.\n\nThe manager stays in control and stitches everything together into one reply.\n\nThis fits any time you want a single agent holding the thread with the user.\n\nIn code, the specialists are literally passed in as tools:\n\n\n\n    manager_agent = Agent(\n        name=\"manager_agent\",\n        instructions=\"You are a translation agent. Use the tools given \"\n                     \"to you to translate. If asked for multiple \"\n                     \"translations, call the relevant tools.\",\n        tools=[\n            spanish_agent.as_tool(tool_name=\"translate_to_spanish\",\n                                  tool_description=\"Translate to Spanish\"),\n            french_agent.as_tool(tool_name=\"translate_to_french\",\n                                 tool_description=\"Translate to French\"),\n            italian_agent.as_tool(tool_name=\"translate_to_italian\",\n                                  tool_description=\"Translate to Italian\"),\n        ],\n    )\n\n\n##  Pattern 2: decentralized handoffs\n\nHere there is no boss.\n\nAgents are peers, and one can _hand off_ the whole conversation to another.\n\nA handoff is a one-way transfer: the new agent takes over execution and the current state, and the original agent steps out.\n\nThis is perfect for triage.\n\nA first agent figures out what the user wants, then passes them to the right specialist.\n\nThe 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.\n\n\n\n    triage_agent = Agent(\n        name=\"Triage Agent\",\n        instructions=\"You are the first point of contact. Assess the \"\n                     \"customer's request and route it to the right \"\n                     \"specialized agent.\",\n        handoffs=[technical_support_agent, sales_assistant_agent,\n                  order_management_agent],\n    )\n\n\n##  Manager vs handoff, quickly\n\nUse the **manager** when you want one voice talking to the user and combining results.\n\nUse **handoffs** when you are happy to let a specialist fully take the wheel.\n\nWhichever you pick, the same rule holds: keep components flexible, composable, and driven by clear prompts.\n\n##  What's next\n\nYou can now run a single agent in a loop, and you know the two ways to scale to many when one is not enough.\n\nThere is one piece left, and it is the one that decides whether your agent is safe to put in front of real users: guardrails.\n\nIn part 3 lets look at layered defenses, prompt injection, PII, and knowing when to pull a human into the loop.\n\nDisclaimer: This article was written by me; AI was used to fix grammar and improve readability.\n\nAI agents write code fast. They also silently remove logic, change behavior, and introduce bugs — without telling you. You often find out in production.\n\ngit-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.\n\nAny feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.\n\n⭐ Star it on GitHub:\n\n\n##  \n        HexmosTech\n       / \n        git-lrc\n      \n\n###  Free, Micro AI Code Reviews That Run on Git Commit\n\n| 🇩🇰 Dansk | 🇪🇸 Español | 🇮🇷 Farsi | 🇫🇮 Suomi | 🇯🇵 日本語 | 🇳🇴 Norsk | 🇵🇹 Português | 🇷🇺 Русский | 🇦🇱 Shqip | 🇨🇳 中文 | 🇮🇳 हिन्दी |\n\n\n\n\n\n\n# git-lrc\n\n## Free, Micro AI Code Reviews That Run on Commit\n\n\n\n\n\n\n\n\n\n\nGenAI 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.\n\n**`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.\n\nIn short, git-lrc helps **Prevent Outages, Breaches, and Technical Debt Before They Happen**\n\n**At a glance:** 10 risk categories · 100+ failure patterns tracked · every commit…\n\nView on GitHub",
  "title": "One Agent or Many? Orchestrating AI Agents Without the Mess"
}