What 30 makers on MakerMap learned about it, in their own words: their best posts on X, filed under Building with AI.
Running 3 specialized agents in production. Strict rule: zero cross-talk.
1. Orchestrator: routes tasks, never writes code.
2. Coder: executes within an isolated sandbox, returns only diffs.
3. Reviewer: reads diffs against strict gates, can only pass or kill.
If an agent doesn’t have a single deterministic exit condition, it doesn't ship.
How many agents are in your active fleet? What is the one rule they are not allowed to break?
We ran 12 controlled trials testing whether structured JSON task contracts beat plain Markdown for coding agents in Sila.
The result: JSON cut prompt tokens by 17%, but acceptance dropped from 5/6 to 3/6.
When a schema omits a single field, models choke. Natural language prompts tolerate missing types far better.
Result: STOP decision. Rollout cancelled.
Tencent open-sourced an agent memory layer (repo already has 28k stars) and the trick isn't the database
it's what it does with your tool logs
long agent runs choke on 200 lines of terminal output. this swaps them for a Mermaid graph of the task. each node has an id pointing to the raw log on disk
agent needs proof? it follows the id back to the exact output. nothing summarized away for good
memory stacks 4 layers: raw chat → atomic facts → scenarios → persona.md
SQLite + BM25 locally, no vector DB server
numbers (their own):
PersonaMem 48% → 76%
SWE-bench 58% → 64% with 33% fewer tokens
WideSearch 61% fewer tokens
one proxy URL and it works with Claude Code, Codex, Hermes, OpenClaw
the boring part of agents is where the wins are
My AI finance advisor made up numbers on my real bank data.
I told it clearly to only repeat figures the app had calculated. It still put two different totals for the same thing in one notification. Neither was in its data.
So the model doesn't do math anymore. Every number comes from SQL, and a few lines of code check each amount in the answer against the data before anyone sees it.
A prompt is a request. A check in code is a guarantee
UPDATE:
after following the twitter hype and seeing people use MASSIVELY PARALLEL agents I realised one thing:
- there are no protocols established and mature enough to handle that
- there is no substantial input of information at start that is properly divided accross threads
- agent cross communication needs to be condensed to a minimum (hashes and handoff, ACK, halt)
Working on tackling this.
For now, running 60 agents is idiotic, it will inevitably reach inefficiency
MDAAI 1.0 was made as extremely verbose, beaurrocratic governance process that ensures responsibility and ownership - it was slow and spent huge amounts of tokens and was not able to guarantee zero errors
MDAAI 2.0 was a massive leap forward. Much less tokens used to enforce the same system. Protocol changes to enforce even stricter ownership and responsibility and proof of work. It also carries metadata of each task containing answers to questions that will be asked by future agents tackling related and affected modules.
MDAAI 2.1 in the making.
These are not versions of the same protocol (mdaai), these are new protocols, independently versioned.
So mdaai 1.0 protocol template is for people who read code and are introducing AI into legacy systems
MDAAI 2.0 is for people who flip and stop reading the code with wast improvements in efficiency. Some of that will find a way into 1.0
—-
MDAAI2.1 is in the making and will tackle the parallelism issue.
Last night I FOR THE FIRST TIME in 8 months had two ai slop errors in my codebase - only because I had forced 12agents through a codebase whose protocol reasonably allows 2-3 individual threads at any time and orchestrated handoff breaks down after adding more.
One big AI agent or a few small ones? I switched to small ones. Why:
1. Context fills up fast and old details get lost
2. Every message costs more as context grows
3. One job per bot is easier to debug
4. You can kill one without breaking the rest
Bookmark this.
At #VercelShip 2026, Anthropic’s Katelyn Lesse shared the blueprint for running massive production agents—like launching an e-commerce store into 24 countries in 3 weeks.
Forget toy chatbots. When you connect her talk with Vercel’s newest releases, four real insights stand out: 🧵👇
1/ Separate the "Brain" from the "Hands."
Stuffing your harness, state, and untrusted code into one sandbox is a trap. If the sandbox crashes, the agent dies.
Anthropic keeps the Brain (state, harness, vault) on persistent servers, while Vercel runs the Hands on disposable Firecracker microVMs.
With the new Vercel Drives, your agent's files and memory survive even when the compute beneath them gets wiped.
2/ Zero credentials in the sandbox.
Treat any environment running AI code as hostile. Keep logs and kill switches outside the sandbox so a clever agent can't edit its own history or turn off its own stop button.
Give the sandbox fake placeholder tokens. When a request leaves, Vercel’s egress firewall and Vercel Connect swap in the real API key on the fly.
3/ "Tokens should have jobs."
One agent with a giant context window gets lazy over long tasks, grades its own homework too generously, and forgets the original goal hours later.
In Claude Opus 4.8 tests with the exact same token budget:
• Pure execution got a perfect score 21% of the time.
• Adding a Grader hit 39%; an Advisor model hit 44%.
• Dreaming hit 71%—pausing after a few runs to reflect and write lessons into memory before continuing.
Offline reflection crushes brute-force execution.
4/ The bigger picture (and the catch).
With Dynamic Workflows, Claude now orchestrates up to 1,000 sub-agents per run—using adversarial agents to stress-test each other's work (catching 66/70 bugs vs. 14–27 for a single agent).
Anthropic is shifting from selling tokens to owning the agent runtime, while Vercel locks down the UI front door and secure sandbox.
The catch for builders? Swarms torch token budgets (you'll need Vercel AI Gateway's new hard budget caps), and stateful Managed Agents mean no Zero Data Retention yet.
Decouple the brain from the hands, broker keys at the edge, and make your tokens dream.
AI Agent production lesson from Day 10:
Retry ≠ safe retry.
If an LLM workflow triggers create_lead, processing the same event twice can create two leads.
Making the happy path work was the easy part.
#AIEngineering #BuildInPublic
the failure mode nobody warns you about with agents:
they report success on a degraded outcome.
my jobs pipeline said success for weeks while it quietly wrote empty results. now every step asserts a row count or it raises.
agents have hard time calculating efficiency
I prompted "scrape x items at that list on this website"
7 minutes later and nothing
then I realized the worker created a sandbox, started a virtual machine, opened a browser, then got stuck on cookies popup
just hit stop, prompted again "you have a built in browser, just use it. I already logged in"
boom, 30 seconds later I had a json file with all the items
so yeah, you need to be SPECIFIC
Before activate: read every credential node, test empty enrichment and missing CRM fields, human gate before WhatsApp/email, check AI credit burn after two debug loops.
I treat my Grok bots as scheduled jobs, not coworkers.
Reply radar. Briefs. Inbox filter.
If a job can't say what it did and when, it gets turned off.