Best Practices for Building Agentic AI Systems
Should anyone be interested I am working on AgentUp:
https://github.com/RedDotRocket/AgentUp
I believe its quite unique as far as agents go. Runtime is config driven, so you can get caching, state management, security (oauth2, jwt) , Tools and MCP capabilities are granted based on scope allocation (file:read, api:write, map:generate) etc, retry handlers, push notifications / webhooks (for long running tasks). This means you can get a fully baked agent built in minutes, using just the CLI.
From there, when you need to customize and write you own business logic, you can code whatever you want and inherit all of AgentUps middleware, and have it as a plugin to the core. This is pretty neat, as it means you're plugins can be pinned as dependencies.
Plugin Example: https://github.com/RedDotRocket/AgentUp-systools
You then end up with a portable agent, where anyone can clone the repo, `agentup run` and like docker, it pulls in all it needs and is serving.
Its currently aligned with the A2A specification, so it will talk to Pydantic, Langchain and Google Agent SDK developed agents.
Its early days, but getting traction.
Previous to this , I created sigstore and have been building OpenSource for many years.
The docs also give a good overview: https://docs.agentup.dev
My favorite post in a long time. Super straightforward, confirms my own early experiences but the author has gone further than I have and I can already see how his hard-won insight is going to save me time and money. One change I’m going to make immediately is to use cheaper/faster/simpler models for 3/4 of my tasks. This will also set things up nicely for having some tasks run on local models in the future.
Am I the only one who cannot stand this terrible AI generated writing style?
These awful three sentence abominations:
"Each subagent runs in complete isolation. The primary agent handles all the orchestration. Simple." "No conversation. No “remember what we talked about.” Just task in, result out." "No ambiguity. No interpretation. Just data."
AI is good at some things, but copywriting certainly isn't one of them. Whatever the author put into the model to get this output would have been better than what the AI shat out.
I recently posted here how I’m seeing success with sub agent-based autonomous dev (not “vibe coding” as I actually review every line before I commit, but the same general idea). Different application, but I can confirm every one of the best practices described in this article, as I came to the same conclusions myself.
These are the same categories of coordination I've been looking at all day, trying to find the sweet spot in how complex the orchestration can be. I tried to add some context where the agents got it into a cycle of editing the code that another was testing and stuff like that.
I know my next step should be to give the agents a good git pattern but I'm having so much fun just finding the team organization that delivers better stuff. I have them consult with each other in tech choices and have picked what I would have picked
The consensus protocol for choices is one I really liked, and that will maybe do more self correction.
Ive been asking them to illustrate their flow of work and asking for decisions, I need to go back and see if that's the case. Probably would be made easier if I get my git experiment flow down.
The future is tooling for these. If we can team up enough that we get consensus approaching something 'safe' the tools we can give them to run in dry/live mode and have a human validate the process for a time and then once you have enough feedback move into the next thing needing fixing.
I have a lot of apps with cobra cli tooling that resides next to the server code. Being able to pump our docs into an mcp server for tool execution is giving me so many ideas.
"Subagent orchestration" is also a really quick win in Claude. You can just say "spawn a subagent to do each task in X, give it Y context".
This lets you a) run things in parallel if you want, but also b) keep the main agent's context clean, and therefore run much larger, longer running tasks without the "race against the context clock" issue.
Love it.
The recovery part was inspiring.
I've written a similar thing - a Pattern Language sort of - and I call the primary Agent "Orchestrator".
Actually, I might steal the Consensus and MapReduce patterns
https://gregorriegler.com/2025/07/12/augmented-coding-patter...
As someone totally outside of this space, how do I build an agent? Are there any languages or libraries that are sort of the de facto standard?
I agreed with much of this, but I started looking into the enterprise ai systems that large companies are making, and they use agent control via software.
So I tried it. It's much better.
Software is just better at handling discrete tasks that you understand, like mapping agent pathing. There's no point giving that to an AI to do.
The Cordinator "Main Agent" should just call the software to manage the agents.
It works really well in comparison.
You can have the software call claude code via command line, sending the prompt in. You have it create full detail logs of what it's doing, and done, and created.
Maybe I'll change my mind, everything is moving so fast, and we're all in the dark searching around for ideas, but so far it's been working pretty well.
You do lose in the middle visibility to stop it.
I also have it evaluating the outputs to determine how well the agents followed their instructions. That seems key to understanding if more context adds value when comparing agents.
I’ve had little success with batching, Eg analysing 50 transactions in one go. It made the rate of hallucinations much higher.
Is there a way to batch as if you’re doing many requests?
I understand that calling it ‘agentic’ is nice for marketing, but most of what is described in this blog post is not related to agents. The design patterns you describe are explicitly non-agentic. Many of the use cases described are better handled by a single LLM call rather than an agent.
Finally, saying that agents can have predictable behavior is wrong (except on simple tasks where you shouldn’t be using an agent anyway). Agents loop and compound their input, making them highly non-deterministic even for the same prompt.
When you say "same output" in
> Every subagent call should be like calling a pure function. Same input, same output. No shared memory. No conversation history. No state.
How are you setting temperature, top k, top p, etc?
"The “Smart Agent” Trap: I tried making agents that could “figure out” what to do. They couldn’t. Be explicit."
So what about this solution is actually agentic?
Overall, it sounds like you sat down and did a proper business process analysis and automated it.
Your subagents for sure have no autonomy and are just execution steps in a classic workflow except you happen to be calling an LLM.
Does the orchestrating agent adapt the process between invocations depending on the data and does it do so in any way more complex than a simple if then branch?
What do you guys use to actually implement this? I used AWS Lambda functions for what is called 'subagents' here and do the main orchestration via long running Step Functions. This is more structured but also allows me to use the common patterns in mentioned in the article (e.g. parallel vs serialized). I noticed however that it can get quite complex and am debating to just implement everything served as a single FastAPI app. I do want to keep it scalable though.
We do lots of fully automated code reviews on code of 5000+ companies in asia.
Let's say my "code reviewer" is main agent, and we are just looking for stuff, i still use "code reviewer" to make "rip grep" queries across thousands of repositories, then i've "rip grep" or "git" as simple functions in the main agent.
I doubt i'll benefit from making subagent for this.
>The Context Explosion: Passing entire conversation history to every agent. Tokens aren’t free.
I often debated if to run sub agents with "little context" then i realized i can just cache the big prompt that goes with main agents and i get no benefit from running subagents with reduced context.
I have been following the growth of agentic AI. While experimenting, I registered a few domains that I am not going to use: - pyagents.com - agentkafe.com
I have listed them on Afternic, but open to suggestions/feedback on whether such names are even useful for projects.
Wow, this is exactly the type of write-up I needed today.
I'm working on a project where I've found that a few orchestrated agents may be the way to go, but I've been having some hiccups which I intended to deal with. But this article covers many of my concerns at a high level.
I found this post very helpful to getting started with agentic systems, what other posts do others recommend?
Structured generation being the magic that makes agents good is true. The fact that the author puts this front and center implies to me that they actually do build working AI agents.
Do you believe that creating sub agents is a violation of the bitter lesson or is simply a way to add more context?
Super practical, no-bullshit write up clearly coming from the trenches. Worth the read.
These subagents look like tools
Author of this post here.
For context, I'm a solo developer building UserJot. I've been recently looking deeper into integrating AI into the product but I've been wanting to go a lot deeper than just wrapping a single API call and calling it a day.
So this blog post is mostly my experience trying to reverse engineer other AI agents and experimenting with different approaches for a bit.
Happy to answer any questions.