DEV Community: Atharva Ralegankar

The Art of Focus: Building a Lean MCP Control Plane

Atharva Ralegankar — Sun, 25 Jan 2026 03:53:15 +0000

Philosophy: One MCP tool. One Transport. One Execution Path. Anything else is scope creep.

The "Zero Scope Creep" Manifesto

In the rush to build "autonomous agents," we often fall into the trap of over-engineering. We build generic plugin architectures, complex plugin discovery mechanisms, and dynamic layout systems before we've even successfully executed a single tool reliably.
If we can't make a single search_web call robust—handling context routing, persistence, retries, and auditing—we have no business adding a second one. This project implements at-least-once execution semantics, placing the burden of idempotency on the tools themselves.

The Stack

Runtime: Node.js (ES Modules)
Persistence: MongoDB (Mongoose)
Execution: Agenda.js (Persistent Job Queue)
Transport: Real MCP Protocol (Stdio / JSON-RPC) via @modelcontextprotocol/sdk ## The Single Execution Path The data flows in one direction. No spaghetti logic. Create workflow → Route Context → Persist Task → Execute (via Stdio Transport) → Audit Log ### 1. The Context Router (The Brain) We stripped the router down to its essence. It looks for intent and dispatches to the single available tool.

// src/core/router.js
export class ContextRouter {
  async route(goal, context) {
    const tasks = [];

    // The One Tool
    if (goal.includes('search')) {
      tasks.push({ 
        type: 'TOOL_CALL', 
        name: 'search_web', 
        input: { query: goal } 
      });
    }
    return tasks; // Simple. Deterministic.
  }
}

2. The Protocol-Compliant Executor (The Muscle)

We don't just "mock" the tool execution anymore. We use the Official MCP SDK to spawn a child process and communicate via standard input/output.

// src/core/mcpClient.js
import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StdioClientTransport } from "@modelcontextprotocol/sdk/client/stdio.js";
async connect() {
  this.transport = new StdioClientTransport({
    command: "node",
    args: ["path/to/server.js"] // Spawns the tool server
  });
  this.client = new Client({ name: "control-plane" }, { capabilities: {} });
  await this.client.connect(this.transport);
}

This ensures that our Control Plane is strictly decoupled. We don't care how the tool works, only that it speaks the MCP Protocol.

3. The Evidence (Real Protocol Handshake)

We can see the actual JSON-RPC handshake occurring in the logs.

[info]: [MCP] Connecting to Internal Server...
[info]: [MCP] Connected via Stdio Transport
[info]: [MCP] Available Tools: {"0":"search_web"}
[info]: [MCP] Requesting Tool Execution: search_web {"query":"Search for \"Model Context Protocol\""}
[info]: [MCP] Tool Response Received

4. Crash Awareness (Defensive Execution)

In distributed systems, networks fail and servers crash. A common failure mode is "Double Execution" where a task completes, the server crashes before state persistence, and the queue redelivers the job.
While we use executionId to track specific job attempts, correctness in this system is achieved via a combination of task state management, persistent retries, and workflow reconciliation. We don't guarantee exactly-once behavior; instead, we ensure that the system eventually converges to a terminal state.

// src/jobs/index.js
defineJob('execute-task', async (job) => {
  const { taskId } = job.attrs.data;
  const task = await Task.findById(taskId);
  // CRASH GUARD: Defensive check against redundant execution
  if (task.status === 'COMPLETED') {
      logger.warn(`[CrashGuard] Task ${taskId} is already COMPLETED. Skipping.`);
      return;
  }

  // Reconciliation on job entry ensures the workflow state is still valid before execution proceeds.
  await reconcileWorkflow(task.workflowId);

  // ... execute tool ...
});

Because we provide at-least-once semantics, tools must be idempotent. Our control plane handles the persistent intent; the execution plane ensures the work is attempted until success or terminal failure.

5. Reconciliation Over Atomicity

Atomic cross-document transactions (e.g., updating a Task and its parent Workflow in one go) were intentionally avoided to minimize database overhead. Instead, we rely on reconciliation as a convergence mechanism.
Every time a task status changes, the system reconciles the entire workflow model. This ensures that the system eventually reaches a consistent terminal state (COMPLETED or FAILED) even if individual updates are interrupted by process crashes. It's a design choice that favors eventual consistency over complex distributed locking.

System Output in Action

When we run our verification script, we see the system in action. This is real output from the production system:

PS D:\Job\Atharva\Projects\mcp-control-plane> node verification_script.js
1. Checking Health...
Health: { status: 'ok', timestamp: '2026-01-20T20:07:16.340Z' }
2. Creating Workflow...
Workflow Created: {
  traceId: 'd5ea06c5-2bfd-4e39-8410-a5f1f83582fa',
  goal: 'Search for "Model Context Protocol"',
  status: 'RUNNING',
  _id: '696fe074c6e929fb3f349c0e'
}
3. Polling for completion...
[1] Status: RUNNING
Last Log: TASK_STARTED { taskId: '696fe074c6e929fb3f349c12', tool: 'search_web' }
[2] Status: COMPLETED
Last Log: WORKFLOW_COMPLETED { workflowId: '696fe074c6e929fb3f349c0e' }

By constraining the scope, we ensured that the infrastructure is correctness-focused.

Is it concurrency-aware? Yes, MongoDB provides document-level consistency.
Is it persistent? Yes, state survives restarts.
Is it observable? Yes, full audit trails. We built a tank, not a Ferrari. And a tank only needs one gun to be effective. --- ## 🏛️ Architecture Reality Check To be transparent about the system's current maturity: ### ✅ What’s Real? These are not mocks. They are correctness-focused implementations:
MCP Integration: Uses the official @modelcontextprotocol/sdk over stdio. It's compatible with any spec-compliant MCP server.
Persistence: Usage of Agenda backed by MongoDB means tasks survive server restarts.
Workflow Reconciliation: Converges workflow state based on task outcomes, validated through crash-injection testing.
Audit Trails: Every state change is immutably logged to the AuditLog collection. ### 🚫 What’s Intentionally Missing?
Authentication: No API keys or OAuth. The system assumes it sits behind a gateway or VPC.
Exactly-Once Semantics: Intentionally traded for simpler at-least-once semantics and idempotency requirements.
Cross-document Transactions: Replaced by eventual consistency and reconciliation logic.
Atomic Task Claiming: The current model allows for rare duplicate starts, handled by idempotency guards.
Complex DAGs: The router currently produces linear or single-step plans. > Failure Model Summary > - At-least-once execution: Work is guaranteed to be attempted. > - Eventual consistency: Achieved via persistent reconciliation. > - Deterministic failure propagation: Task failures terminalize parent workflows. > - No zombie workflows: State convergence ensures every intent reaches a result. ### 🚀 What I’d Do Next (With More Time)
Extract the Worker: Split the Agenda worker into a separate microservice for independent scaling.
Redis-based Locking: Replace MongoDB document-level consistency with Redis (Redlock) for higher throughput task claiming.
Topological Sort: Upgrade the scheduler to handle dependency graphs (Task B waits for Task A).
mTLS for MCP: Switch from stdio transport to SSE (Server-Sent Events) with mutual TLS for remote tool execution.

Beyond Chatbots: How Multi-Agent AI Systems Are Revolutionizing Software Engineering

Atharva Ralegankar — Sun, 17 Aug 2025 18:10:55 +0000

Hey there, fellow engineers!

Ever feel like AI-powered chatbots are just scratching the surface of what's possible in software engineering? You and I both know the future is so much richer and wilder. Today, let's talk about something that's starting to change how we work: multi-agent AI systems. Not just one "co-pilot," but coordinated teams of AI agents working alongside us—sometimes autonomously, sometimes in sync with our intentions—to streamline, automate, and even reimagine day-to-day engineering.

Curious about what that really means? Let's dive deep.

1. From Chatbot Assistants to Autonomous AI Agents

Most of us started seeing AI as helpful when OpenAI's ChatGPT, Copilot, and other chat-based assistants entered our workflow. They're cool—but they're still fundamentally "helpers," not independent workers.

But what if we could deploy fleets of AI agents, each specializing in a particular domain (like code review, DevOps, or testing), working together and negotiating with each other to get entire workflows done? Now we're talking about "multi-agent systems." These are AI agents that can make decisions, trigger actions, coordinate projects, and, most importantly, collaborate or compete with each other.

Sounds sci-fi? Not anymore.

2. Meet Your Dev Team of AI Agents

Picture this:
You have a cloud-native app, and you want to automate your whole DevOps pipeline—from CI/CD to testing to incident response. Here's how a multi-agent system could break down the tasks:

Agent A: Monitors Github for new pull requests and checks styles.

Agent B: Runs automated tests and evaluates code coverage.

Agent C: Handles build/deployment to staging and production.

Agent D: Monitors production health, auto-creates tickets when issues are detected.

Now, throw in some negotiation (Agent B needs Agent A to pass first!) and conversation: these agents can message each other's endpoints, share artifacts, and "decide" who leads on which job.

This isn't theoretical. Leading open-source frameworks like LangChain Agents, Microsoft Semantic Kernel, and AutoGen are making such orchestrations practical for all of us.

3. Tech Stack: Building Blocks of Multi-Agent AI

Let me show you what's actually involved—no magic, just powerful tools:

Large Language Model (LLM) Coordinator: The "brain" that interprets instructions and delegates to capable agents.

Specialized Tool-Use Agents: Each can be tailored for DevOps, data scraping, testing, you name it.

Memory/Trace Log: Persistent context and traceability so agents "remember" what happened.

Communication Protocols: JSON, REST, gRPC—or good old HTTP.

Want to see a working example? Let's build a simple multi-agent collaboration using AutoGen:

3.1. Sample Code: Python Multi-Agent System with AutoGen

Suppose we want two agents—"Coder" and "Reviewer"—to collaborate and review a simple function.

# Install dependencies: pip install pyautogen openai

import autogen
from autogen.agentchat.user_proxy_agent import UserProxyAgent
from autogen.agentchat.assistant_agent import AssistantAgent

# Setup OpenAI config (replace with your API key)
config = {
    "llm": "openai",
    "config_list": [
        {
            "model": "gpt-3.5-turbo",
            "api_key": "YOUR_OPENAI_API_KEY"
        }
    ]
}

# Define the Users/Agents
reviewer = AssistantAgent(
    name="Reviewer",
    system_message="You review Python code for bugs and optimization.",
    llm_config=config
)

coder = AssistantAgent(
    name="Coder",
    system_message="You write Python code following best practices.",
    llm_config=config
)

user_proxy = UserProxyAgent(
    name="User",
    code_execution_config={"work_dir": "python_scripts"}
)

# Let's simulate a round of conversation:
init_msg_coder = "Write a Python function that checks if a string is a palindrome."
user_proxy.initiate_chat(
    agent=reviewer,
    messages=[
        ("User", init_msg_coder),
        ("Coder", "Here is the function implementation:\n"
                  "def is_palindrome(s):\n"
                  "    return s == s[::-1]")
    ],
    n_results=2  # Limit conversation rounds
)

What's happening here?

The Coder writes code.
The Reviewer checks it for bugs or improvements.
UserProxy can step in, run the code, and manage the workflow.

You can expand this by plugging in more agents, adding task dependencies, or pinging external APIs. And yes—this pattern scales to entire engineering workflows!

4. How Multi-Agent Systems Are Automating Real Workflows

Let's see some practical scenarios where agent squads shine:

Automated Ticket Triage (Real-World Example)

Imagine:
Your engineering backlog is overflowing with GitHub issues and Jira tickets. You spin up a trio of agents:

Classifier Agent: Reads new issues, tags them (bug, feature, doc).

Skill-Matcher Agent: Cross-references issue context with your team's expertise.

Scheduler Agent: Assigns the ticket and alerts the team Slack.

Result:
Tickets get triaged and assigned minutes after they're created. Your devs focus on building, not managing.

You could wire this up using something like LangChain's Agent Executor and connect with Slack, GitHub, and Jira APIs.

5. Emergent Behaviors: Surprises in Agent Teams

Here's where it gets really interesting—when you let agents operate with minimal intervention, their interactions can create emergent behaviors:

Unexpected collaboration: Agents "invent" new coordination strategies you didn't hard-code.

Failure recovery: Agents self-diagnose and retry failed deployments—even pinging humans when truly stumped.

Occasional chaos: Miscommunications or loops ("Agent A blames Agent B, B blames A!") can force you to improve agent prompts and boundary conditions.

This feels like managing a living system more than a set of static scripts. There's new room for creativity… and for debugging!

6. Human-in-the-Loop or Fully Autonomous?

Here's a choice every engineering leader must make:

Supervised agents: Humans always approve/reject agent actions. Safe, trusted, but slower.

Semi-autonomous agents: Agents complete easy tasks and only ask for help on edge cases.

Fully autonomous: Agents have wide permissions; humans monitor via dashboards and logs.

Most modern projects start with supervised or semi-autonomous, then push autonomy over time as trust and capability build.

7. Technical Deep Dive: Building a Scalable Agent Schema

You don't always need heavyweight orchestrators—sometimes a YAML or JSON config file and some HTTP endpoints are enough to create a modular system!

Example: YAML Agent Config (Simplified)

agents:
  - name: "DevOpsAgent"
    capabilities:
      - "build"
      - "deploy"
    endpoint: "https://devops.internal/api"
  - name: "TestAgent"
    capabilities:
      - "run_tests"
      - "report_coverage"
    endpoint: "https://ci.internal/api"
  - name: "DocAgent"
    capabilities:
      - "generate_docs"
      - "tag_codebase"
    endpoint: "https://docs.internal/api"
workflow:
  - step: "build"
    agent: "DevOpsAgent"
    next: "run_tests"
  - step: "run_tests"
    agent: "TestAgent"
    next: "generate_docs"
  - step: "generate_docs"
    agent: "DocAgent"
    next: "deploy"
  - step: "deploy"
    agent: "DevOpsAgent"
    end: true

With such a config, your orchestration logic just reads the config and forwards tasks as HTTP requests between agents.

8. Challenges & Open Problems

Let's not sugarcoat: going "multi-agent" comes with brand-new challenges.

Security risks: Can agents be tricked? Hijacked? Proper RBAC and API isolation are essential.

Observability: How do you debug a hive of agents? You'll want comprehensive logs and tracing.

Coordination complexity: How do you prevent loops or deadlocks? Add clear protocols, heartbeats, and failure modes.

Ethical guardrails: If agents start making decisions that affect users (deploying, changing prices, etc.), you need clear ethical boundaries.

9. The Future: Self-Improving Agent Teams

Imagine agents that, after each sprint, analyze what went wrong and improve their own code and decision logic. Or agents that propose new plugins to boost productivity.

That's not fantasy—early research labs are already exploring reinforcement learning and LLM-based "self-updating" agents. The era of the self-improving engineering team is just over the horizon.

10. Conclusion

As you can see, the leap from single, prompt-based AI helpers to coordinated teams of specialized AI agents is set to revolutionize how we build, ship, and maintain software. You don't need to be at Google or Microsoft to start—many of these tools are open source and ready for your own wild workflow experiments.

Ready to architect your own multi-agent AI system?
Let me know what you dream up—I'd love to hear from fellow builders who believe, like me, that the real magic happens when agents work together.

The GPT-5 Unboxing: Is This the AI We’ve Been Waiting For?

Atharva Ralegankar — Thu, 07 Aug 2025 19:41:58 +0000

OpenAI has officially released GPT-5, and it's nothing short of a technological milestone. From new model sizes to practical business integration, the GPT-5 family redefines what we can expect from AI in the workplace. Here's a comprehensive breakdown of what just launched — and why it matters.

🚀 What's New in GPT-5?

GPT-5 isn't a single model — it's a family of models optimized for various devices, use cases, and latency requirements:

GPT-5: The flagship model, capable of advanced reasoning, deep memory, and complex instruction following.
GPT-5 Mini: A lightweight model for fast, low-latency experiences.
GPT-5 Nano: Designed to run directly on-device for edge computing use cases.

These variants enable organizations to choose the right intelligence-per-cost ratio for their needs.

📚 Full specs → platform.openai.com/docs/models/gpt-5

🧠 Smarter and More Humanlike

According to the technical whitepaper, GPT-5 outperforms GPT-4 and GPT-4o in:

Coding
Long-form content generatio
Multi-step reasoning
Tool usage (via function calling or API integration)
Memory recall and personalization

This leap is thanks to:

Improved architecture
Longer context windows
Better alignment techniques

It’s also more steerable — meaning it better sticks to tone, style, or safety guidelines.

💼 Designed for Work

GPT-5 is deeply optimized for business environments. It integrates with productivity tools, CRM systems, and data dashboards.

Enterprises can:

Create AI teammates with persistent memory
Automate workflows
Generate reports, write code, summarize docs
Integrate GPT into internal apps securely

The GPT-5 for Work initiative reaffirms OpenAI’s shift from consumer-grade tools to real enterprise AI infrastructure.

🖥️ Available Today on ChatGPT Team

GPT-5 is already rolling out on ChatGPT Team, giving early access to businesses looking to get ahead.
It will launch for ChatGPT Enterprise and ChatGPT Edu on August 14.

💡 Ideal for teams in:

Engineering
Research
Marketing
Customer Support
Operations

📱 On-Device Intelligence with GPT-5 Nano

With GPT-5 Nano, OpenAI is making a serious push into edge computing. These ultra-small models can run directly on laptops and phones, enabling:

Offline AI assistants
Secure, fast local inference
Personalized features without cloud dependency

📎 Learn more → GPT-5 Nano Docs

⏱️ GPT-5 API Rate Limits

Rate limits ensure fair and reliable access to the API by placing specific caps on the number of requests or tokens used within a given time period. Your usage tier determines how high these limits are, and tiers automatically increase as you send more requests and spend more on the API.

🔍** What Do These Limits Mean?**

*RPM *(Requests Per Minute): Controls how many API calls you can make per minute.
*TPM *(Tokens Per Minute): Caps the total number of tokens (input + output) processed per minute.
Batch Queue Limit: Dictates the max number of tokens you can queue for batch processing.

These limits scale with your usage and are designed to support everything from personal projects to enterprise-scale applications.

✨** Closing Thoughts**

GPT-5 represents the maturation of general-purpose AI into specialized, secure, and reliable tools for modern workflows. Whether you're a startup founder or an enterprise IT lead, GPT-5 opens new doors to automation, productivity, and intelligence.

This isn't just an upgrade — it's a shift in how we work.

👉 Explore GPT-5: GPT-5

Follow me for more updates on AI, productivity tools, and developer-first tech revolutions.