DEV Community: Tech Trails

Protocols in Agentic Systems

Deepak Patil — Tue, 11 Aug 2026 19:12:32 +0000

Picture an office where every employee speaks a different language, uses a different filing system, and refuses to fill out the same form twice. That's most multi-agent AI systems before someone introduces a protocol. Agents are brilliant in isolation and chaotic in groups, and the only thing standing between "chaotic" and "coordinated" is a shared set of rules about who says what, when, and in what format.

This is the unglamorous half of agentic AI. Nobody writes a viral demo about a well-designed message schema. But spend a week debugging an agent swarm that silently corrupts its own state, and you'll start treating protocols with the reverence usually reserved for database transactions.

What a Protocol Actually is

A protocol, in the agentic context, is an agreed-upon contract for communication. It answers four questions:

Who can talk to whom?
What shape does a message take?
When does a turn end and the next one begin?
What happens when something goes wrong?

That's it. It's not a model architecture, not a prompting trick, not a clever chain-of-thought technique. It's plumbing. And like plumbing, you only think about it when it leaks.

A useful mental model: if a single LLM call is a sentence and a ReAct loop is a conversation with yourself, a protocol is etiquette for a conversation with strangers. The moment more than one autonomous component is involved - another agent, a tool, a human, or a database - etiquette stops being optional.

Why Agents Need Protocols More Than Humans Do

Humans get away with sloppy communication because we're extraordinary at inferring intent. Say "Can you grab that?" while pointing vaguely at a table, and another person fills in the gaps using context, tone, and shared history.

Agents don't do this gracefully. An LLM agent calling a tool with a malformed argument doesn't pause and think, "They probably meant the CSV, not the JSON." It either fails loudly, fails silently, or - worse - succeeds in a way nobody intended. Without a protocol, here's a fairly typical failure mode in a two-agent setup:

Agent A: "Here's the summary you asked for: [wall of unstructured text]."
Agent B: (expecting a JSON object with a summary key, gets a string instead, crashes trying to parse it)

Nobody did anything "wrong" exactly. Agent A produced a perfectly reasonable summary. Agent B had a perfectly reasonable expectation. The system failed because nobody agreed in advance on the shape of the handoff. This is the agentic equivalent of two people agreeing to meet "later" without specifying a time — technically an agreement but practically useless.

Tool-Calling Protocols

The most common protocol any agent encounters: a structured schema (usually JSON) describing what a tool accepts and returns. This is the seatbelt of agentic systems - unglamorous, occasionally annoying, and the reason you don't go through the windshield when a model decides to get creative with its output format.

Example: OpenAI's function calling, Anthropic's tool-use API, and Google's function declarations all do the same fundamental thing - they force the model to emit a structured payload ({"name": "get_weather", "arguments": {"city": "Pune"}}) instead of a free-text guess at what a tool call should look like. The protocol isn't the tool. It's the agreed format for requesting the tool.

Agent-to-Agent (A2A) Communication Protocols

This is the layer that gets the least attention and causes the most pain. Tool-calling protocols govern how an agent talks to a function. A2A protocols govern how an agent talks to another agent - a fundamentally messier problem, because the other party isn't a deterministic API. It's another model with its own context, its own interpretation of the task, and its own way of going off-script.

A workable A2A protocol typically needs to define:

Identity — Which agent is speaking and what role it's speaking from (researcher, critic, planner, or executor).
Message envelope — a consistent structure wrapping the actual content, e.g. {"from": "researcher", "to": "writer", "type": "handoff", "payload": {...}}.
Conversation state — whether this message is a new task, a follow-up, a correction, or a final answer, so the receiving agent doesn't have to guess.
Termination signal — an explicit way to say "I'm done, here's the result" versus "I'm still working," so the system doesn't poll forever or cut an agent off mid-thought.

Industry example: Google's Agent2Agent (A2A) protocol is a direct attempt to standardise exactly this - giving agents built on different frameworks (say, one built with LangGraph and another with CrewAI) a common envelope for discovering each other's capabilities and exchanging tasks, regardless of which vendor or framework built them. Without something like this, every pair of agent frameworks needs a custom translator, which scales about as well as you'd expect - that is, badly.

Frameworks like AutoGen and CrewAI bake a version of A2A messaging into their internals already - when a "manager" agent delegates to a "worker" agent, there's a defined message format underneath, even if it's framework-specific rather than a true open standard. The trend industry-wide is towards pulling that logic out of individual frameworks and into shared, framework-agnostic protocols.

Context and Tool-Sharing Protocols (MCP)

How does an agent know what tools and data exist without every integration being hand-wired? This is where the Model Context Protocol (MCP) comes in - an open standard for connecting AI applications to external tools, data sources, and systems through a single, consistent interface.

Think of it as the difference between every appliance in your house needing its own proprietary charger versus everything just using USB-C. Mildly annoying to standardise, wildly convenient once it's done.

Concrete example: Without MCP, an agent that needs to read files from Google Drive, query a Postgres database, and check GitHub issues needs three separate, custom-built integrations - each with its own auth handling, its own response format, and its own edge cases to maintain. With MCP, each of those becomes an MCP server that exposes its capabilities (e.g., list_files, run_query, get_issue) in a standard format. Any MCP-compatible agent can then talk to any of them the same way, without bespoke glue code per integration. Anthropic's Claude Desktop, for instance, can connect to a local filesystem MCP server or a Slack MCP server using the same underlying protocol - the agent doesn't need a different communication style for each one.

This is also why MCP gets compared to the Language Server Protocol (LSP) in developer tooling. Before LSP, every code editor needed a custom integration for every programming language's autocomplete and linting. LSP lets editors and language tooling agree on one interface, so any editor could support any language without N×M custom integrations. MCP is making the same bet for agents and tools.

Coordination and Turn-Taking Protocols

In a multi-agent workflow, somebody has to decide whose turn it is to act, or you get the digital equivalent of a conference call where four people start talking at once and two never get a word in.

This is a real protocol layer, not just a scheduling detail, because it defines a contract: only one agent (or a defined subset) may act at a time, and there's an explicit rule for handing control back. A few concrete patterns in current use:

Supervisor/orchestrator pattern (LangGraph): A central orchestrator node decides which agent runs next based on the current state and routes control explicitly via a graph of edges. No agent decides on its own that it's "next" - the orchestrator decides for it.
Round-robin and group chat (AutoGen): AutoGen's GroupChat manager cycles through agents in turn or selects the next speaker based on the conversation so far, with an explicit manager component responsible for the decision, rather than leaving it to the agents to sort out among themselves.
Role-based sequential handoff (CrewAI): Agents are assigned roles in a defined sequence (researcher → writer → editor), and a task is only "live" for one role at a time, with output passed forward once that role completes.

In each case, the underlying agreement is the same: turn-taking can't be implicit. Someone - a manager process, a graph,or a queue - has to own the decision of who acts next, or the system devolves into agents talking over each other or, just as commonly, everyone waiting for someone else to go first.

Error and Fallback Protocols

What happens when a tool call fails, a response times out, or an agent returns something nonsensical? This counts as a protocol because it's a contract too - just one for the unhappy path instead of the happy one. A system without this contract doesn't fail gracefully; it fails wherever it happens to fail, which in production is usually somewhere inconvenient.

Concrete patterns worth knowing:

Retry with backoff: if a tool call times out, retry a fixed number of times before escalating, rather than retrying forever or giving up immediately.
Typed error responses: instead of throwing a raw exception, a tool returns a structured error ({"status": "error", "reason": "rate_limited"}) that the calling agent can actually reason about and act on.
Escalation to a human-in-the-loop: when an agent's confidence is low or a tool repeatedly fails, the protocol defines a handoff to a human reviewer instead of letting the agent guess indefinitely — a pattern increasingly built into orchestration frameworks as a first-class node, not an afterthought.
Circuit breakers: If a downstream tool fails repeatedly, the protocol stops calling it for a cooldown period instead of hammering a dead service — borrowed directly from distributed systems design.

A Worked Example

Consider a simple two-agent system: a Researcher agent that searches the web and a Writer agent that drafts a summary from the research.

Without a protocol, the Researcher might return:

Found some interesting stuff about quantum computing, here's what I think...

The Writer agent, expecting structured findings, has to guess what's a fact, what's the Researcher's opinion, and what's even usable. It's working from vibes.

With a protocol, the contract might look like this:

{
  "from": "researcher",
  "to": "writer",
  "type": "handoff",
  "status": "complete",
  "findings": [
    {"claim": "...", "source": "...", "confidence": "high"}
  ]
}

Now the Writer knows exactly what it's receiving, can validate it before using it, and - crucially - can fail predictably if the Researcher sends something malformed, rather than failing mysteriously. The difference between these two systems isn't model quality. It's whether anyone bothered to define the interface.

Designing Your Own Protocol: A Short Checklist

If you're building a multi-agent system and rolling your own protocol — which, early on, you often will - a few things tend to matter more than they first appear:

Make failure a first-class message, not an exception. Agents should be able to say "I don't know" or "this failed" in the same structured format they use for success - not as a stack trace that breaks the contract.
Version your message schema. The moment you have two agents and a schema change, you have a compatibility problem. Future you will be grateful for a "version": "1.2" field.
Keep payloads minimal but explicit. Don't make the receiving agent infer anything; it could have just been told
Log everything that crosses the boundary. Inter-agent communication is the first place to look when debugging emergent weirdness, so make it inspectable.
Assume the other agent is a stranger, not a collaborator. Defensive parsing isn't paranoia in agentic systems - it's the default posture.

Protocols don't make agentic systems smarter. They make them legible to each other and to the humans trying to debug them at midnight. The flashy parts of agentic AI (reasoning loops, tool use, autonomous planning) get the conference talks. Protocols get the postmortems.

But every durable multi-agent system, from A2A and orchestrator frameworks to standards like MCP, is ultimately betting on the same unsexy truth: agents that agree on how to talk to each other will always outlast agents that are merely good at talking.

The Orchestrator in Agentic Systems

Deepak Patil — Sat, 08 Aug 2026 09:20:28 +0000

A multi-agent system without an orchestrator is just a collection of agents. Each one is capable, but none of them coordinated. They might all be excellent at their individual jobs - searching the web, writing code, calling APIs - but without something deciding what gets done, in what order, by whom, and what to do when a result comes back wrong, the system does not behave like a system. It behaves like a group project with no project manager.

The orchestrator is the project manager. Its job is not to do the work. Its job is to make sure the work gets done - and that is a harder, more subtle problem than it sounds.

What an orchestrator is responsible for

An orchestrator does four things, and only these four things:

1. Decompose the goal. Turn a high-level objective into a concrete set of subtasks. This is a planning problem, not an execution problem. The orchestrator decides what needs to happen, not how to do it.

2. Route tasks to the right workers. Match each subtask to an agent capable of doing it. This requires knowing what tools and capabilities each worker has - not in detail, but well enough to delegate correctly.

3. Manage state across the workflow. As workers return results, the orchestrator decides what those results mean for the remaining plan. Sometimes a result changes the plan entirely. Sometimes it confirms the next step. The orchestrator holds the full picture.

4. Synthesise the final output. Worker outputs are partial. The orchestrator assembles them into a coherent response and decides when the goal has been met.

Notice what is absent: the orchestrator does not call APIs, does not run code, does not search the web. It reasons about work and routes it. The moment an orchestrator starts executing, it loses the focus that makes it good at coordination.

Building one from scratch

Here is a minimal orchestrator in Python. It plans upfront, delegates to type workers, and synthesizes results:

import json

def orchestrator(goal: str, workers: dict) -> str:
    # Step 1: plan
    plan_prompt = f"""
    Goal: {goal}
    Available workers: {list(workers.keys())}

    Return a JSON array of steps: [{{"task": "...", "worker": "..."}}]
    Return JSON only, no explanation.
    """
    plan = json.loads(llm(plan_prompt))

    # Step 2: execute each step, collect results
    results = []
    for step in plan:
        worker = workers[step["worker"]]
        result = worker.run(step["task"])
        results.append({"task": step["task"], "result": result})

    # Step 3: synthesise
    synthesis_prompt = f"""
    Original goal: {goal}
    Worker results: {json.dumps(results, indent=2)}

    Synthesise a final answer from these results.
    """
    return llm(synthesis_prompt)

Three things in this snippet are worth pulling apart.

The orchestrator calls llm() twice - once to plan, once to synthesize - but never once to execute. Execution is entirely delegated. If you find yourself adding a tool call directly inside the orchestrator loop, stop and ask whether a worker should own that instead.

The plan is a first-class object - a list of typed steps, not an implicit chain of thought. This means you can inspect it, log it, replay it, and re-plan from any point when something goes wrong.

Results are kept verbatim before synthesis. The orchestrator does not summarise early. It gives the synthesis step the full picture, letting the model decide what is relevant. Premature summarization is where context gets lost.

Re-planning when reality diverges

A fixed plan fails the moment a worker returns an unexpected result. A real orchestrator needs to decide: Does this change the remaining plan?

def orchestrator_with_replan(goal: str, workers: dict) -> str:
    plan = initial_plan(goal, workers)
    completed = []

    while plan:
        step = plan.pop(0)
        result = workers[step["worker"]].run(step["task"])
        completed.append({"task": step["task"], "result": result})

        # check if the result warrants re-planning
        replan_prompt = f"""
        Remaining plan: {plan}
        Latest result: {result}

        Does this result change what should happen next?
        If yes, return a revised plan as JSON. If no, return null.
        """
        revision = llm(replan_prompt)
        if revision and revision != "null":
            plan = json.loads(revision)

    return synthesise(goal, completed)

This is the plan-and-execute pattern from the last post made concrete. The orchestrator works from a checklist but checks after each result whether the checklist still makes sense. The loop terminates when the plan is empty, not when a fixed number of steps has run.

What frameworks add

Writing an orchestrator from scratch gives you control and understanding, but production use cases introduce problems the snippet above does not handle: state that needs to persist across restarts, workflows that need branching and loops, and debugging when something goes wrong three levels deep. This is where the frameworks come in.

LangGraph

LangGraph represents a workflow as a directed graph - nodes are agents or functions, edges are transitions between them, and a centralized StateGraph holds shared state across the whole run.

from langgraph.graph import StateGraph, END
from typing import TypedDict

class WorkflowState(TypedDict):
    goal: str
    plan: list
    results: dict
    final_answer: str

graph = StateGraph(WorkflowState)

graph.add_node("planner", planner_node)
graph.add_node("researcher", researcher_node)
graph.add_node("coder", coder_node)
graph.add_node("synthesiser", synthesiser_node)

graph.add_conditional_edges(
    "planner",
    route_to_worker,           # function that reads state and picks next node
    {"research": "researcher", "code": "coder"}
)

graph.add_edge("researcher", "synthesiser")
graph.add_edge("coder", "synthesiser")
graph.add_edge("synthesiser", END)

graph.set_entry_point("planner")
app = graph.compile()

The graph-based model earns its complexity because it makes branching and cycles explicit. The conditional edge above is not hidden inside a prompt - it is code. You can read the graph and know exactly what routes exist. LangGraph also ships with checkpointers that persist state to disk or a database, so a workflow that crashes halfway through can resume from the last checkpoint rather than starting over.

The honest tradeoff: a simple workflow that would take 40 lines in plain Python takes closer to 120 in LangGraph. You pay in boilerplate. You get auditability, resumability, and explicit control flow in return.

AutoGen

AutoGen takes a different approach. Instead of a graph, it models orchestration as message-passing between agents. A GroupChat manager decides which agent speaks next based on context, and agents broadcast their replies so everyone shares the same conversation history.

from autogen import AssistantAgent, UserProxyAgent, GroupChat, GroupChatManager

planner = AssistantAgent("planner", system_message="Break goals into tasks.")
researcher = AssistantAgent("researcher", system_message="Search and retrieve facts.")
coder = AssistantAgent("coder", system_message="Write and run Python code.")
critic = AssistantAgent("critic", system_message="Review outputs for errors.")

group_chat = GroupChat(
    agents=[planner, researcher, coder, critic],
    messages=[],
    max_round=12
)

manager = GroupChatManager(groupchat=group_chat)
planner.initiate_chat(manager, message="Build a data pipeline for X.")

The GroupChatManager is the orchestrator here. AutoGen v0.4 rebuilt this around an actor model where each agent runs independently and communicates through typed messages - a cleaner design for truly concurrent workflows.

The full-context broadcast is AutoGen's key architectural bet: every agent sees the whole conversation, which means specialist agents can catch problems earlier in the chain. The cost is that the context window fills faster in long workflows.

CrewAI

CrewAI uses a role-driven model. You define a crew of agents with named roles, assign tasks, and let the framework handle delegation. Configuration-first rather than code-first - most of the setup lives in YAML:

from crewai import Agent, Task, Crew, Process

researcher = Agent(role="Researcher", goal="Find accurate information",
                   backstory="Expert at web research", tools=[search_tool])
writer = Agent(role="Writer", goal="Produce clear summaries",
               backstory="Experienced technical writer")

research_task = Task(description="Research topic X", agent=researcher)
write_task = Task(description="Write a summary of the research", agent=writer)

crew = Crew(
    agents=[researcher, writer],
    tasks=[research_task, write_task],
    process=Process.sequential
)

crew.kickoff()

Process.hierarchical switches to an orchestrator model where a manager agent routes tasks dynamically rather than following a fixed sequence. CrewAI is the fastest path from idea to running prototype, but teams consistently report hitting its ceiling 6–12 months in when workflows grow beyond sequential or simple hierarchical patterns - at which point a migration to LangGraph tends to follow.

The most honest guidance: start from scratch to understand the pattern, then adopt a framework when you need what it specifically offers - not because frameworks are the default. LangGraph is the current production default for teams that need long-running, resumable workflows with explicit control flow. CrewAI is the right choice when you need something working this week and can accept the ceiling. AutoGen is strongest when agents genuinely need to debate and revise rather than execute a fixed plan.

The orchestrator's failure modes

The orchestrator is the single point of failure in a multi-agent system, which means its failure modes are expensive.

Over-delegation. The orchestrator sends a task to a worker that is underspecified. The worker returns garbage. The orchestrator synthesises the garbage. Build task schemas - typed descriptions of what a worker expects - and validate them before dispatch, not after.

Plan rigidity. An upfront plan that doesn't re-evaluate when results diverge will execute confidently toward a wrong answer. Build in a replan check after any result that introduces new information.

Silent worker failures. Workers that fail quietly return None or an empty string, which the orchestrator may synthesise as if it were real output. Workers should fail loudly with typed errors that the orchestrator can inspect and route around.

Context overload. The orchestrator accumulates results from every worker. In a long workflow, its context fills with raw worker outputs. Pass summaries, not raw transcripts, unless the raw content is genuinely needed for synthesis.

The orchestrator's value is its deliberate ignorance of the details. It does not know how to search the web, run code, or call an API. It knows what needs doing and who should do it. That separation - reasoning about work versus doing work - is what allows multi-agent systems to scale beyond what any single agent could manage alone.

The loop is still the heartbeat. The orchestrator is the brain that decides how many loops to start, what they should do, and when to stop.

Single-Agent vs Multi-Agent System

Deepak Patil — Sat, 01 Aug 2026 18:33:43 +0000

When one loop is enough - and when you need a team

The previous post ended with a loop: reason, act, observe, repeat. That loop, running inside a single agent, can handle a surprising range of tasks. But spend enough time building agents and you'll hit a wall. The task is too long for one context window. Two subtasks need to run at the same time. One part of the problem requires a specialist that would be noise everywhere else. When you hit that wall, you have a choice: push harder on the single agent or split the work across multiple agents. Knowing which to reach for - and why - is what this post is about.

What a single agent actually is

Before comparing, it's worth being precise. A single agent is one model, one context window, and one tool set, running one loop. Everything it has learned about the task lives in that growing history of thoughts, actions, and observations. Its memory is its context.

That constraint is the source of both its simplicity and its limits.

Where a single agent excels:

Tasks that fit comfortably in one context window
Linear workflows where each step depends on the last
Problems where keeping a shared mental model matters more than speed
Prototyping - one loop is trivial to trace and debug.

Where it breaks down:

Long tasks that exceed the context limit midrun
Tasks with independent subtasks that could be parallelised
Workflows that need different capabilities in different phases
Any situation where one agent failing silently kills the whole job

What a multi-agent system adds

A multi-agent system is two or more agents coordinating to complete a task. Coordination can mean many things - one agent spawning others, agents running in parallel and reporting back, and a pipeline where each agent's output is the next agent's input. The common thread is that no single agent owns the whole task.

This unlocks three things:

Parallelism. If you need to research five companies simultaneously, a single agent does them sequentially. A multi-agent system spawns five subagents and gets all five results at once. For I/O-bound tasks - anything involving search, API calls, or file reads - this is the primary win.

Specialisation. A coding agent prompted and tooled for writing Python is better at writing Python than a generalist agent. A multi-agent system lets you route subtasks to agents built for them - a planner, a researcher, a coder, a critic — each with the right system prompt and the right tools.

Context management. Each subagent gets a fresh, focused context. Instead of one agent accumulating 50,000 tokens of noise from early steps, a subagent receives only what it needs to do its job. The orchestrator summarises and routes; the workers stay sharp.

The orchestrator–worker pattern

The most common multi-agent architecture is a two-level hierarchy: one orchestrator and one or more workers.

The orchestrator receives the goal, makes a plan, and delegates subtasks. It does not do the work itself - it decides what the work is and who does it. Workers receive a scoped task, run their own loop, and return a result. They don't know about each other or the overall goal.

def orchestrator(goal, worker_agents):
    plan = llm(f"Break this goal into subtasks: {goal}")
    # plan = [{"task": "...", "agent": "researcher"}, ...]

    results = {}
    for step in plan:
        worker = worker_agents[step["agent"]]
        results[step["task"]] = worker.run(step["task"])

    final_answer = llm(f"Synthesise these results: {results}")
    return final_answer

Each worker.run() is the same agent loop from the previous post - reason, act, observe, repeat - but scoped to a single subtask. The orchestrator never picks up a tool itself; it reads a plan and routes. The workers never see the big picture; they just solve their piece.

This separation matters. It keeps orchestrator context lean (plans and results, not tool noise) and keeps worker context focused (one task, right tools, nothing else).

Parallelising with subagents

When subtasks are independent, run workers concurrently. In Python, asyncio or ThreadPoolExecutor are the usual choices:

from concurrent.futures import ThreadPoolExecutor

def run_parallel(tasks, worker):
    with ThreadPoolExecutor(max_workers=len(tasks)) as pool:
        futures = {pool.submit(worker.run, task): task for task in tasks}
        return {task: f.result() for f, task in
                [(v, k) for k, v in futures.items()]}

Two things to watch. First, rate limits: five agents hitting the same API simultaneously will hit quotas faster than one agent doing it sequentially. Build in back-off logic at the worker level, not just the orchestrator level. Second, result merging: parallel results arrive out of order and may conflict. The orchestrator's synthesis step needs to handle gaps and contradictions, not assume clean, uniform output.

When multi-agent is the wrong answer

Multi-agent systems have real costs, and reaching for them too early is one of the most common mistakes in agent engineering.

Complexity compounds. A single agent failing is easy to diagnose - you read the trace. Multiple agents failing is a distributed systems problem. Which agent failed? Did the orchestrator misparse the result? Did the worker receive a bad task? Every hop is a new failure surface.

Latency can get worse, not better. Parallelism helps I/O-bound tasks. For CPU-bound or model-call-bound work, the overhead of spawning agents, merging results, and making extra orchestration calls can exceed what a single focused agent would have taken.

Context hand-offs lose information. When the orchestrator summarises a worker's result to pass to the next, it makes decisions about what to keep. Those decisions are lossy. A single agent that ran the whole task never had to summarise itself.

The honest default: start with a single agent. Add a second agent when you have a concrete bottleneck - context overflow, a parallelism win you can measure, or a capability mismatch you cannot solve with a better prompt and better tools.

A practical decision framework

Situation	Reach for
Task fits in context, linear flow	Single agent
Task exceeds context mid-run	Orchestrator + summarising subagents
Independent subtasks, I/O-bound	Parallel workers
Phases need different tool sets	Specialist workers per phase
Need a second opinion on outputs	Critic agent in the loop
Prototyping or debugging	Single agent - always start here

A single agent is not a stepping stone to multi-agent. It is the right architecture for a large class of tasks and the one you should default to until you have a specific reason to split work. Multi-agent systems earn their complexity when tasks genuinely exceed what one context window can hold, when parallelism produces a real speed win, or when specialist agents meaningfully outperform a generalist on a defined subtask.

The loop does not change. What changes are, who owns which part of it, and how do the pieces report back?

Agent Memory & Context Engineering

Deepak Patil — Tue, 28 Jul 2026 18:41:11 +0000

How agents remember - and why deciding what to forget is the real skill

An agent that starts every step with a blank mind cannot really pursue a goal. It would reintroduce itself to you on every message, forget what it just tried, and repeat the same mistake forever. Memory is what turns a stateless model into something that accumulates - that knows who you are, what it has already done, and what it learned last Tuesday. This post is about how that works and, more importantly, about the discipline of deciding what an agent should remember at all.

The context window is not memory.

The first thing to unlearn: a model’s context window is not its memory. The context window is working memory - RAM, not a hard drive. It is finite, it is reset on every request, and every token in it costs money and dilutes the model’s attention. Stuffing an entire conversation history and knowledge base into the prompt does not scale, and past a point it actively hurts - the model loses the important signal in a sea of stale detail. Real memory lives outside the window and is selectively loaded into it when needed.

Four kinds of memory

Borrowing loosely from cognitive science, agent memory is usually split into four types, and good systems use all of them:

Short-term/working memory - the current conversation and the agent’s recent thoughts and observations. Lives in the context window.
Long-term episodic memory - a record of what happened: past conversations, decisions, and the outcomes of previous tasks.
Long-term semantic memory - facts and knowledge: who the user is, domain information, documents. This is what retrieval-augmented generation pulls from.
Procedural memory - how to do things: learned skills, tool-use patterns, and reusable strategies.

Short-term memory: the rolling buffer

The simplest memory is just keeping recent turns in the prompt. The problem is that conversations outgrow the window, so the standard move is to keep the last few turns verbatim and summarise the older ones into a compact note:

def build_context(history, window=6):
    recent = history[-window:]
    older = history[:-window]
        if older:
            summary = llm(f"Summarize this conversation so far:\n{older}")
            return [f"Summary so far: {summary}", *recent]
    return recent

This keeps the prompt bounded while preserving the gist of what came before. It is crude, but it is the backbone of almost every chat agent in production.

Long-term memory: embeddings and vector search

To remember across sessions, an agent writes information to an external store and retrieves it later by meaning rather than exact keywords. The mechanism is embeddings: each piece of text is converted into a high-dimensional vector, stored in a vector database, and later retrieved by finding the vectors closest to the current query. This is what lets an agent recall a relevant fact even when you phrase your question completely differently from how the fact was stored.

# Write a memory
vec = embed("User prefers window seats and vegetarian meals.")
store.add(id="pref-1", vector=vec, text="User prefers window seats and vegetarian meals.")

# Later, retrieve by meaning
query_vec = embed("book me a flight to Delhi")
hits = store.search(query_vec, top_k=3)
context = "\n".join(h.text for h in hits)   # injected into the prompt

That retrieval step is what gives an agent its long memory without bloating the context window: you store everything but load only the handful of memories relevant to the moment.

Why vector search alone isn’t enough

Vector similarity is powerful but blunt, and it is worth knowing its limits before you lean on it. Similarity relies on relevance - not recency, not authority, not workflow state. It will happily surface an outdated preference the user changed yesterday or a fact from a draft that was later overruled, simply because the words are close. It does not understand which memory is current, which is authoritative, or where you are in a multi-step task. Production memory systems layer on recency weighting, source ranking, and explicit state to compensate. Memory in 2026 is treated as a real engineering discipline with measurable trade-offs, not a database you bolt on and forget.

Context engineering: the real skill

All of this rolls up into the discipline people increasingly call context engineering: deliberately deciding what goes into the context window on every single step. Prompt engineering asks How do I word the instruction? Context engineering asks What information should the model see right now, and what should I leave out? It is closer to managing a tight working-memory budget than to writing clever prompts.

A recent and influential pattern is Agentic Context Engineering (ACE), which treats context as something the agent actively curates through a three-role loop: a Generator produces an attempt, a Reflector evaluates it and flags what was missing or wrong, and a Curator distils the lesson into a growing “playbook” that improves future context. Reported results show meaningful accuracy gains on agent benchmarks without retraining the underlying model - the improvement comes entirely from feeding it better context. That is the whole thesis of context engineering in one experiment.

Practical patterns to start with

Summarise old turns, keeping recent ones verbatim - bounded prompt, preserved gist.
Retrieve, don’t dump - pull only the top few relevant memories per step instead of the whole store.
Tag memories with time and source so you can prefer recent, authoritative information over stale matches.
Write back what matters - after a task, save the durable facts and lessons, not the entire transcript.

The takeaway

Memory is what separates a chatbot from an agent that genuinely accumulates competence over time. But the headline isn’t “store everything” - it’s the opposite. The skill is curation: deciding, on every step, the smallest set of information that lets the model act well and leaving the rest in long-term storage until it’s needed. Treat context as critical infrastructure, and your agents get sharper, cheaper, and more reliable all at once.

Next in the series: One agent can only do so much. We’ll look at multi-agent systems - orchestration, the A2A protocol, and how to split a goal across a team of specialised agents without the whole thing collapsing into chaos.

Tools, Function Calling & MCP

Deepak Patil — Thu, 23 Jul 2026 16:29:21 +0000

How agents reach into the real world - and how to do it without creating a security nightmare

A language model on its own is a brain in a jar. It can reason beautifully about the weather and tell you nothing about whether it is actually raining outside, because it has no senses and no hands. Tools are the senses and hands. They are the single feature that turns a model that can talk about booking a flight into an agent that can actually book one. In the last post we saw the agent loop; this post is about the Act step inside that loop.

What a tool actually is

Strip away the jargon and a tool is two things: a function, and a description the model can read. The function is ordinary code - a database query, an HTTP call, a shell command. The description is a schema that tells the model the tool’s name, what it does, and what arguments it takes. The model never sees your code; it only sees the schema and decides, in the moment, whether this tool is the right one for the goal in front of it.

def get_weather(city: str) -> dict:
    """Return current conditions for a city."""
    return weather_api.current(city)

# The schema is what the MODEL sees:
{
    "name": "get_weather",
    "description": "Get current weather conditions for a city.",
    "parameters": {
        "type": "object",
        "properties": {"city": {"type": "string", "description": "City name, e.g. 'Mumbai'"}},
        "required": ["city"]
    }
}

The one rule that keeps you safe: decide vs. execute

Here is the most important sentence in this entire post. The model decides; your code executes. When a model “calls a tool,” it does not run anything - it returns a structured request that names a function and its arguments. Your application receives that request, decides whether it is allowed, runs the real function, and feeds the result back into the loop.

The LLM should decide what to do, but never be the thing that does it. Keep a layer of your own code between the model’s intent and any real-world effect.

That gap between intent and execution is where you put validation, permission checks, rate limits, and human approval for anything dangerous. Collapse that gap - let the model run code directly - and you have handed an unpredictable system the keys to your infrastructure.

# The full decide -> execute -> observe cycle

response = client.chat(messages=history, tools=schemas)
for call in response.tool_calls:
    if not is_allowed(call.name, call.args):     # YOUR guardrail
        result = "Error: not permitted."
    else:
        result = REGISTRYcall.name  # YOUR code runs it
    history.append({"role": "tool", "name": call.name, "content": str(result)})
    final = client.chat(messages=history)            # model uses the results

Designing tools the model can actually use

An agent is only as capable as its tools are well-designed, and most agent failures trace back to a badly described or badly scoped tool rather than a weak model. A few principles go a long way:

Name and describe for the model, not for you. cancel_order(order_id) with a one-line description of when to use it beats a clever internal name the model has to guess about.
Keep each tool narrow. One tool, one job. A single do_everything tool with a mode flag forces the model to reason about your implementation instead of the task.
Validate inputs and fail informatively. Return “Error: city ‘Xyz’ not found, did you mean a valid city name?” rather than a stack trace. The model reads that error and corrects itself on the next loop.
Prefer idempotency. Agents retry. A tool that charges a card twice when called twice is a liability; design so repeats are safe.

The M×N problem, and why MCP exists

Once tools work, a scaling problem appears. If you have M agent applications and N systems you want to connect (Slack, GitHub, your database, Google Drive), the naive world requires M×N custom integrations - every app re-implementing a connector to every system. The Model Context Protocol (MCP), introduced by Anthropic and now broadly adopted, collapses that into M+N. MCP is an open standard - often described as “USB-C for AI tools” - that defines a common way for a model to discover and call tools exposed by any compliant server.

The division of labour in the 2026 agent stack is clean: MCP standardizes how agents talk to tools and data; the Agent-to-Agent (A2A) protocol standardizes how agents talk to each other. Build a tool once as an MCP server and any MCP-aware client - LangGraph, CrewAI, ADK, a desktop assistant - can use it without bespoke glue.

# A minimal MCP server exposing one tool (Python SDK)

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("weather-server")

@mcp.tool()
def get_weather(city: str) -> dict:
    """Get current weather conditions or a city."""
    return weather_api.current(city)

if __name__ == "__main__":
    mcp.run()   # any MCP client can now discover and call get_weather

The payoff is an ecosystem effect: the catalogue of ready-made MCP servers keeps growing, so connecting an agent to a new system increasingly means pointing it at an existing server rather than writing an integration.

Tools are your attack surface

Every tool you give an agent is also a door someone could walk through. A tool that runs shell commands or sends money is exactly as dangerous in an agent’s hands as in an attacker’s, and prompt injection - hostile instructions hidden in a web page or document the agent reads - can trick an agent into misusing the tools it has. Treat tool access as a security boundary, not a convenience:

Least privilege. Give each agent the narrowest set of tools its job requires - nothing more.
Never auto-execute irreversible actions. Payments, deletions, and trades should require explicit human confirmation, not an agent’s say-so.
Validate and sanitize all tool inputs, exactly as you would for any untrusted user, because in effect they are

Tools are what make an agent useful, and MCP is making them composable across the whole ecosystem. But the discipline that matters most is the gap you keep between the model’s decision and the real action - that gap is where your validation, permissions, and human oversight live. Get the tool design and that boundary right and you have an agent that is both genuinely capable and safe to put in front of real users.

Inside The Agent Loop

Deepak Patil — Tue, 21 Jul 2026 16:26:15 +0000

How an agent actually thinks and acts: ReAct, tool calling, and the loop that powers every agent

In the first post, we described an agentic system as software that can plan, reason, use tools, and execute multi-step workflows. This sentence hides the most important idea in the whole field. What is actually happening when an agent “thinks”? The honest answer is surprisingly simple, and once you see it, every agent framework on the market stops looking like magic and starts looking like a single design pattern repeated with variations.

The pattern is a loop. A plain language model answers your prompt once and stops. An agent wraps that same model in a loop (its output is fed as its next input and so on) that keeps running - reasoning, taking an action, observing the result, and reasoning again - until the goal is met. That loop is the heartbeat of every agent you will ever build.

From one-shot answers to a loop

A chatbot is a function: text in, text out, done. The model never finds out whether its answer was any good. An agent breaks that single shot into a cycle. After each step it gets feedback from the real world and uses that feedback to decide what to do next. This is the difference between a student who writes an exam answer and walks away and a mechanic who turns a bolt, checks whether the engine starts, and adjusts.

The most influential way to structure that cycle is the ReAct pattern, introduced by Yao et al. in 2022. ReAct stands for Reason + Act, and it interleaves three things on every turn:

Thought - a short chain-of-thought where the model reflects on the situation and decides what to do.
Action - a concrete step, usually calling a tool or an API.
Observation - the result that action produced, fed straight back into the model.

By forcing the model to reason in the open and ground each decision in a real observation, ReAct reduces hallucination: the model cannot quietly invent a fact when the next line of the transcript is the actual output of a search it just ran.

A traced example

Suppose the goal is "What was the closing price of the stock the CEO of Tesla most recently tweeted about?” A ReAct trace might look like this:

Thought: I need to find Elon Musk's most recent tweet about a stock.

Action: search_tweets(user="elonmusk", topic="stock")

Observation: "Just bought more $X ..." (posted 2h ago)

Thought: The ticker is X. I need today's closing price.

Action: get_quote(ticker="X")

Observation: { "close": 41.80, "currency": "USD" }

Thought: I now have the answer.

Action: finish("The closing price was $41.80.")

Notice that no single model call could have answered this. The agent had to act, look at what came back, and only then decide its next move. That is the entire value proposition of the loop.

Building the loop from scratch

Stripped of any framework, an agent loop is about a dozen lines. The model returns a structured decision; your code executes it and feeds the result back:

def run_agent(goal, tools, max_steps=8):
    history = [system_prompt(goal, tools)]
    for _ in range(max_steps):
        decision = llm(history) # model reasons + picks an action
        if decision.action == "finish":
            return decision.answer
        tool = tools[decision.action]
        result = tool(**decision.args)   # YOUR code runs the tool
        history.append(decision)
        history.append(f"Observation: {result}")
    return "Stopped: step budget exhausted."

Three details in that snippet matter more than they look. First, the loop has a hard step budget (max_steps). Without it, a confused agent will happily call tools forever and burn through your API bill. Second, the model never executes anything - it only names an action and arguments; your code decides whether and how to run it. Third, every observation is appended to history, so the model’s context grows with what it has learned.

ReAct text vs. native tool calling

There are two ways to get that decision out of the model. The original ReAct approach asks the model to write its thoughts and actions as text, which you then parse. Modern models offer native tool calling (also called function calling): you hand the model a set of typed function schemas, and it returns a structured JSON object naming the function and its arguments - no fragile text parsing required.

Native tool calling: the model returns structured intent, not prose.

tools = [{
        "name": "get_quote",
        "description": "Get the latest market quote for a ticker symbol.",
        "parameters": {
            "type": "object",
            "properties": {"ticker": {"type": "string"}},
            "required": ["ticker"]
        }
}]

response = client.chat(messages=history, tools=tools)
call = response.tool_calls[0]    # {name: "get_quote", args: {ticker: "X"}}

The trade-off is real and worth understanding. Text-based ReAct is transparent and model-agnostic - you can read the reasoning, and it works on any model, even ones without a tool-calling API. Native tool calling is more efficient and reliable - structured output, fewer round trips, and the model can request several tools at once - but the reasoning behind a call is less visible. In practice most production agents use native tool calling and recover transparency through tracing and logging.

When one loop isn’t enough: plan-and-execute

Pure ReAct decides its next step one observation at a time, which is flexible but can wander on long tasks. A common evolution is plan-and-execute: the agent first drafts a full plan and then executes the steps, replanning only when reality diverges. Separating slow, expensive planning from fast tactical execution tends to handle complex multi-step workflows more efficiently than reacting from scratch every turn. You can think of ReAct as improvising and plan-and-execute as working from a checklist you’re allowed to revise.

Where loops go wrong

The loop is powerful precisely because it is open-ended, and that is also where the failure modes live. Agents get stuck repeating the same failing action, loop until the budget runs out, or call an expensive tool dozens of times. The defenses are unglamorous but essential: a hard step limit, detection of repeated identical actions, a cost ceiling, and clear tool error messages so the model can recover rather than retry blindly. Treat every observation as something the model might misread, and design your tools to fail loudly and informatively.

The takeaway

Every agent - from a customer-support bot to GitHub Copilot’s agent mode - is, at its core, this loop: “reason, act, observe, repeat, until done." "Frameworks add memory, multiple agents, and orchestration on top, but they are all variations on the same heartbeat. Once you can write the loop yourself, you understand agents from the inside, and every framework becomes a convenience rather than a mystery.

Next in the series, the Act step deserves its own post. We’ll go deep on tools, function calling, and the Model Context Protocol - how agents actually reach into the world without becoming a security liability.

Introduction to Agentic Systems

Sarthak Jain — Sun, 19 Jul 2026 17:11:55 +0000

LLM’s are part of everyday life

With the rise of LLM’s over the past decade there has been surge in development/usage of textual chat applications. Chatbots using these LLM models are becoming ineradicable parts of human life.

Considering this organizations are trying to build bots, softwares tailoring the user experience for their businesses. Simply put, Agentic Systems are just LLM’s on loop, and they represent the next step in this evolution. Instead of simply responding to prompts, they can plan, reason, make decisions, use tools, and execute multi-step workflows to achieve a goal.

For eg. You ask gemini to add an event on your calendar.

An Agentic System

As defined by Google

Agentic AI is an advanced form of artificial intelligence focused on autonomous decision-making and action. Unlike traditional AI, which primarily responds to commands or analyzes data, agentic AI can set goals, plan, and execute tasks with minimal human intervention. This emerging technology has the potential to revolutionize various industries by automating complex processes and optimizing workflows.

Agentic system is an AI system that is focused on orchestration and operation of agents to perform actions by using LLMs as underlying technology. To simplify, an agentic system is nothing but a real world organization where each worker (Agent) performs a specific goal contributing towards the broader organizational goal.

As the AI systems are evolving there is need of bringing complex workflows within AI systems to cater varied customer use-cases. These workflows involve multiple actions and decisions which traditional LLM’s are not capable of performing. This leads to the introduction of agents which is an

autonomous entity designed to perform specific tasks

An agent is a standalone system which uses LLM at its core and is tailored to → understand complex user objectives → break it down in small and precise tasks → perform analysis → plan execution → perform the tasks with provided context and tools → reach the desired objective by completing all sub tasks.

Working of Agents

An agent works as an individual worker or part of multiple workers in the system. An individual agent is designed to perform a single task with higher efficiency and correctness. An agent has following components:

Goal → Reasoning Engine → Context → Tools → Feedback

Goal : Goal can be defined as a objective which needs to be achieved.
Reasoning Engine : A reasoning engine is a LLM which is called using a special prompt to get the specific task done.
Context : Every agent has context of its own which is related to the task it’s supposed to achieve.
Tools : Tools are external integrations that helps the agent to complete it’s task.
Feedback : With every objective an agentic systems learns and becomes more accurate in future.

Every agentic system starts with a base agent (In Single Agent System) that starts the initial flow of the task. A general use of base agent is to understand the user prompt and generate the plan to achieve desired goal.

In case of multi agent systems a base agent is responsible to break user query down into completable smaller tasks or goals. It acts as a orchestrator for the entire multi-agent system. Once the tasks are decided, a base agent calls respective agents and assigns them sub tasks along with input if any. Others agents may be single or again a part of multi agent system. The worker agents complete the sub tasks either by reasoning, calling tools, interacting with external systems or even fetching data from various sources. The base agent then combines the outcomes of sub-agents in calling order → and synthesizes the final output by transforming the results.

Agentic System In Action

A real world use-case of Agentic System is “Github Copilot Agent Mode” which is available today in most of the IDE’s. It is the next evolution in AI assisted software development. It can achieve multi step tasks including reading files, analyzing the code, performing code edits, running cli commands and many more.

It can be used for:

Researching the architecture
Fixing Bugs
Improving test coverage and code quality
Updating Documentation
Resolving code errors

Details on how it works can be found here -

introducing-copilot-agent-mode#_how-it-works

Here is a sample working agent code in Java built with ADK - https://github.com/Deepcodr/JobPilotAgent

Beyond the prompt

Agentic Systems represent a significant shift in AI development. Rather than simply responding to prompts, it enables AI to tackle complex, multi-step tasks that traditional applications struggle to handle.
For developers, understanding agentic systems is becoming increasingly important as organizations move toward autonomous workflows and AI-driven operations. The future of AI is not just about generating answers; it's about taking meaningful actions to achieve outcomes.