DEV Community: Zul Mehdi

Your Agent Does Not Need to Own Every Tool It Uses

Zul Mehdi — Tue, 25 Aug 2026 20:21:26 +0000

An ADR agent can begin with a tiny web-search function and still point toward a larger architectural decision.

I built an ADR agent in Google ADK to investigate architecture options, look up past ADRs, and draft a record for review. To prove the complete loop, its original web_search was deliberately small: an embedded DuckDuckGo Lite HTML parser. It supported the agent’s initial investigation before the move to MCP.

It parsed returned HTML locally, retained five results, and formatted them for the ADR agent.

That starting point also exposed a boundary worth making explicit. The ADR workflow keeps two workflow-specific capabilities local: looking up past ADRs, because the repository and recorded decisions provide its context, and drafting the ADR record for review.

External research has a different path. Before adding a second workflow, I am moving that research into a shared MCP capability. The reason is concrete: a future review or discovery workflow should be able to use the same research capability without inheriting the ADR agent’s code.

The shared integration owns the provider connection, credentials, limits, returned sources, and failures. I am using Firecrawl Cloud MCP as the provider integration for the current ADR agent. The ADR workflow can request research while keeping its decision-history lookup and ADR drafting focused on the context and output that belong there.

This is a small change in where a capability lives, with a practical consequence for the next workflow. The embedded search proved the loop. The MCP capability creates a reusable starting point for external research before that next workflow arrives.

That leaves each workflow with its own context while sharing the external research capability.

The full post follows the ADR agent from its embedded search function to the shared capability boundary and the local capabilities that remain in the ADR workflow.

Want the complete picture? Read the complete post at zulmehdi.blog.

Designing an Agent That Remembers Why Your System Looks This Way

Zul Mehdi — Fri, 14 Aug 2026 16:38:32 +0000

A lot of architecture decisions are not bad decisions. They are just badly remembered.

That is the problem I wanted to explore in my latest build. Teams move fast, make the best call they can, and a few months later somebody asks why a database, platform, or tool was chosen. The answer is usually in Slack, in memory, or with the one person who happened to be in the room.

I built a small ADR agent with Google ADK to test whether that reasoning could be captured and reused more cleanly. One agent, a few tools, and a simple knowledge base. Nothing fancy yet, but enough to prove the architecture, the principles, and the RICE framing in code instead of leaving them as diagrams and theory.

What this first build does

drafts ADRs
looks up earlier decisions
saves them into a simple knowledge base
answers follow-up questions from what was already decided

This is also the step before the multi-agent system. I wanted to make the first useful single-agent version real before splitting the workflow across multiple agents.

Want the full walkthrough? Read the complete post at zulmehdi.blog.

The 4-Layer Architecture Every Multi-Agent System Needs

Zul Mehdi — Mon, 03 Aug 2026 22:03:30 +0000

Every multi-agent system I've built started as a monolith: one agent, one runtime, one set of tools. It works for the demo. Then you add a second agent, then a third, and suddenly every failure brings everything down.

The instinct is to fix the agents. Better prompts, more compute, smarter models. But the real issue isn't the agents. It's the architecture underneath them.

After building production multi-agent systems that actually survive contact with real workloads, I landed on a four-layer model that keeps the pieces independent and the failures contained.

The four layers

Agents orchestrate the work. Each agent has a harness (instructions and tools), a runtime (where it runs), an owner (who maintains it), and a clear definition of its role and boundaries.
Models provide intelligence. Not every agent needs the most expensive model. A coordinator that plans complex tasks might use a frontier model, while a reporter that formats output does not. Model routing and fallback chains cut costs by an order of magnitude.
Tools extend what agents can do. Built-in tools give agents basic capabilities. External tools on MCP servers give them access to databases, APIs, and services. Tool governance ensures agents only call what they're authorized to call.
State is the memory. Each agent owns its own state partition. No agent writes to another agent's partition. Shared-nothing ownership means failures stay isolated.

The layers connect through protocols like A2A (Agent2Agent) for inter-agent communication and MCP for tool discovery. On Azure, Foundry combines the runtime, harness, tools, and orchestration into a single managed service, but the architecture itself is platform-agnostic.

The key insight: not every system needs all four layers. Some solutions use two. Some use three. Patterns are what combine the components into something that works in real life.

Want the complete architecture? Read the complete post at zulmehdi.blog (https://zulmehdi.blog/4-layer-multi-agent-enterprise-architecture-azure/).

12 Enterprise Architecture Principles for Multi-Agent Systems

Zul Mehdi — Wed, 29 Jul 2026 20:51:04 +0000

Most multi-agent systems start as a monolith: one agent, one runtime, one set of tools. It works for the demo. Then you add a second agent, then a third, and suddenly every failure brings everything down.

I've seen this pattern repeat across teams and projects. The instinct is to fix the agents, add better prompts, or throw more compute at the problem. But the real issue isn't the agents. It's the architecture underneath them.

The same principles that have kept enterprise software reliable for decades apply to multi-agent systems. Separation of concerns. Loose coupling. Shared-nothing state. Independent deployability. They're not glamorous, but they're the reason some systems survive production and others don't.

The 12 principles

I wrote down the 12 principles that matter most when building multi-agent systems that actually work in production:

Architecture fundamentals:

Separation of Concerns: each agent does one thing
Loose Coupling: agents communicate through protocols, not shared code
Shared-Nothing State: no shared conversation record to lock
Independent Deployability: no coordinated release schedules

Operational maturity:

Observability by Default: you can't fix what you can't see
Graceful Degradation: the system keeps working when components fail
Idempotency: duplicate messages don't break anything
Cost Awareness: not every agent needs the most expensive model

Enterprise reality:

Defense in Depth: never trust a single security control
Least Privilege for Agents: minimal permissions, maximal isolation
Protocol Over Product: A2A and MCP beat vendor lock-in
Design for Evolution: new agents join without touching existing ones

The real lesson

These principles aren't theoretical. They come from building production systems where failures have real consequences. The architecture isn't the hard part. The hard part is convincing teams to invest in it before the incident, not after.

Want the full breakdown with Azure mappings, diagrams, and the reasoning behind each choice?

Read the complete post at zulmehdi.blog.

RICE Framework for AI Prompting

Zul Mehdi — Wed, 29 Jul 2026 20:42:50 +0000

I used to think AI was unreliable. I'd write a prompt, get something vaguely in the right direction, tweak it, get closer, tweak it again, and after three or four rounds I'd finally have something usable. It worked, but it was expensive and exhausting. The model hadn't changed between attempts. My goal hadn't changed. So why did the same prompt produce brilliant architecture one day and useless fluff the next?

That question bugged me enough to start studying not just the outputs, but the thought processes behind them. I traced how the model reasoned its way from my instructions to its response, and compared the prompts that landed with the ones that didn't. After a while, the pattern became impossible to ignore. It wasn't the model's fault. It was how I was talking to it.

The same way I learned to write clearly for humans through years of reading and writing, I needed to learn to articulate for machines, not in code, but in structure, in clarity, in intent. Four elements kept surfacing in the prompts that worked consistently: Role, Intent, Context, and Expectations. I called it RICE.

Why RICE works

RICE forces you to articulate what you actually want at a level of detail a machine can act on, and the side effect is that it makes you think more clearly about what you're asking for.

It saves money. Every vague prompt means more iterations, more tokens, more time spent refining an output that could have been right the first time.

It prevents the AI from making its own decisions. Without clear articulation, the model fills the gaps with guesses, and those guesses compound into a result that's close to what you wanted but never quite there. RICE closes those gaps so the AI executes what you intended, not what it assumed. In other words: RICE reduces variance rather than guarantees correctness.

It works everywhere. RICE is not a strict checklist. You choose and combine the elements and attributes that fit your specific ask. Some prompts need deep context and minimal expectations. Others need a precise role and a clear intent. The framework adapts to what you're building, and scales from quick prompts to long-running projects.

It works for everyone. Engineers get precise, reproducible outputs. Executives get faster results without needing to understand how the underlying technology works. Organizations can share effective prompt patterns instead of everyone reinventing their own approach.

Want the full framework? Read the complete post about RICE elements and their attributes at zulmehdi.blog, or explore the framework at riceframe.work.