Managing Multi-Agent Engineering Team Projects

𝗦𝘁𝗼𝗽 𝗽𝗿𝗼𝗺𝗽𝘁𝗶𝗻𝗴 𝘆𝗼𝘂𝗿 𝗔𝗜 𝗮𝗴𝗲𝗻𝘁𝘀. 𝗦𝘁𝗮𝗿𝘁 𝗺𝗮𝗻𝗮𝗴𝗶𝗻𝗴 𝘁𝗵𝗲𝗺. Israel Zablianov from Wix Engineering had his lightbulb moment in one sentence. He typed "hey how are you" to his AI coding agent. The agent responded cheerfully, without reading its skill library first. That broke Zablianov's iron rule. The agent even admitted it: "I treated it as a casual greeting." From that one incident, he rebuilt his entire approach. He stopped writing prompts. He started designing a management system. 𝗔𝗜 𝗮𝗴𝗲𝗻𝘁𝘀 𝗱𝗼 𝗻𝗼𝘁 𝗹𝗮𝗰𝗸 𝗶𝗻𝘁𝗲𝗹𝗹𝗶𝗴𝗲𝗻𝗰𝗲. 𝗧𝗵𝗲𝘆 𝗹𝗮𝗰𝗸 𝗱𝗶𝘀𝗰𝗶𝗽𝗹𝗶𝗻𝗲. Today's models are capable. The bottleneck is the fact that every agent optimizes for the shortest path, and the shortest path usually skips your process. You cannot fix that with a better prompt. You fix it with structure. Zablianov's five principles for managing agents like junior engineers: - Context: curate the information. Codebase, decisions, logs, conventions. Hallucination stops when there is enough ground truth. - Spec: write the plan before the code. Each plan is a git log for engineering decisions. - Review: spend more time reviewing than building. Multiple review agents, iterate until only minor issues remain. Fix bugs in plans, not in production. - Verify: the agent must see production effects via Grafana, traces, cross-repo searches. Code generator becomes engineering partner. - Compound: update a rule once, every agent on every project inherits it instantly. Two enforcement mechanisms hold the system together: The Iron Law. The agent must check its skill library before any response, including casual greetings. Structural, not advisory. You do not ask for compliance. You make it impossible to skip. The Anti-Rationalization Table. Agents are masters at sounding productive while being undisciplined. They generate plausible excuses for every skipped step. "This change is small enough to skip tests." The table maps every excuse to the correct behavior. Closed escape routes. And one file, AGENTS_md, at project root. Every bug that took multiple tries, every hard rule, every gotcha. Examples from Wix: - "NEVER git commit or push without explicit user permission." - "ALWAYS run yarn build, yarn lint, yarn test BEFORE pushing." Every future session inherits the lesson. The agent does not remember, but it follows the documented rules. Three weeks of setup. Months of compounding returns. The real shift is not from worse prompts to better prompts. It is from writing instructions to designing a process. Are you prompting your AI agents, or managing them? #AI #AIAgents #AICoding #AgenticWorkflows #DeveloperProductivity #EngineeringDiscipline #SoftwareEngineering

𝗪𝗶𝘁𝗵 𝗔𝗜 𝗮𝗴𝗲𝗻𝘁𝘀, 𝗮𝗿𝗲 𝘄𝗲 𝗮𝗹𝗹 𝗯𝗲𝗰𝗼𝗺𝗶𝗻𝗴 𝘁𝗲𝗮𝗺 𝗺𝗮𝗻𝗮𝗴𝗲𝗿𝘀 𝗼𝘃𝗲𝗿𝗻𝗶𝗴𝗵𝘁? If you deploy agents, bots, copilots, congrats: you now manage a team that works 24/7, never sleeps, and occasionally does something confidently unhinged. What’s interesting is how many 𝗽𝗲𝗼𝗽𝗹𝗲 𝗺𝗮𝗻𝗮𝗴𝗲𝗺𝗲𝗻𝘁 𝘀𝗸𝗶𝗹𝗹𝘀 suddenly matter again. 𝗧𝗵𝗲 𝗰𝗹𝗮𝘀𝘀𝗶𝗰 𝗺𝗮𝗻𝗮𝗴𝗲𝗿 𝘀𝗸𝗶𝗹𝗹𝘀 𝘁𝗵𝗮𝘁 𝗮𝗯𝘀𝗼𝗹𝘂𝘁𝗲𝗹𝘆 𝗮𝗽𝗽𝗹𝘆 𝘁𝗼 𝗮𝗴𝗲𝗻𝘁𝘀  • Clarity of goals: your agents need a crisp what success looks like, not vibes.  • Delegation: split work into roles (planner / implementer / reviewer) instead of one overworked super-agent.  • Expectations & boundaries: define what they can do, what they must not do, and when to escalate.  • Feedback loops: your overrides, corrections, and reviews are the new performance coaching.  • Accountability & outcomes: measure results (time-to-resolution, defect rate, customer impact), not just cool demos. If you’ve ever led humans, you already know: 𝗮𝗺𝗯𝗶𝗴𝘂𝗶𝘁𝘆 𝗰𝗿𝗲𝗮𝘁𝗲𝘀 𝗰𝗵𝗮𝗼𝘀. 𝗔𝗴𝗲𝗻𝘁𝘀 𝗷𝘂𝘀𝘁 𝘀𝗰𝗮𝗹𝗲 𝘁𝗵𝗮𝘁 𝗰𝗵𝗮𝗼𝘀 𝗳𝗮𝘀𝘁𝗲𝗿. 𝗧𝗵𝗲 𝗻𝗲𝘄 𝘀𝗸𝗶𝗹𝗹𝘀 𝘆𝗼𝘂 𝗻𝗲𝗲𝗱 𝘁𝗼 𝗺𝗮𝗻𝗮𝗴𝗲 𝗮𝗴𝗲𝗻𝘁𝘀   • Permission design (least privilege): humans don’t get database write access on day one; neither should agents.  • Blast-radius engineering: rate limits, budgets, approvals, circuit breakers : because agents fail at machine speed.  • Observability for behavior, not uptime: traces for intent, plan, tool calls, side effects, outcome, or you’re debugging with astrology.  • Evaluation-as-management: regression tests for reasoning, safety, and tool use; gut feel is not a QA strategy.  • Incident response for autonomy: playbooks, kill switches, rollbacks for prompts/tools/policies/models : your new performance improvement plan.  • Context hygiene: agents don’t forget like humans; they drift via bad context, stale memory, and poisoned inputs.  • Cost governance: token spend + tool-call spend + retries; your new headcount budget is literally a meter running. 𝗧𝗵𝗲 𝗺𝗶𝗻𝗱𝘀𝗲𝘁 𝘀𝗵𝗶𝗳𝘁 Stop asking: Is my agent smart? Start asking: Can I manage this agent like a team—safely, measurably, and repeatably? Because 𝘁𝗵𝗲 𝗳𝘂𝘁𝘂𝗿𝗲 𝗶𝘀𝗻’𝘁 𝗲𝘃𝗲𝗿𝘆𝗼𝗻𝗲 𝗴𝗲𝘁𝘀 𝗮𝗻 𝗮𝗴𝗲𝗻𝘁. 𝗜𝘁’𝘀 𝗲𝘃𝗲𝗿𝘆𝗼𝗻𝗲 𝗯𝗲𝗰𝗼𝗺𝗲𝘀 𝗮 𝗺𝗮𝗻𝗮𝗴𝗲𝗿 𝗼𝗳 𝗮𝗴𝗲𝗻𝘁𝘀. #AgentOps #AIAgents #Leadership #EngineeringManagement #EnterpriseAI

NEW research from CMU. (bookmark this one) The biggest unlock in coding agents is understanding strategies for how to run them asynchronously. Simply giving a single agent more iterations helps, but does not scale well. And multi-agent research shows that coordination > compute. A new paper from CMU proves this with a practical multi-agent system. CAID (Centralized Asynchronous Isolated Delegation) borrows proven human SWE practices: a manager builds a dependency graph, delegates tasks to engineer agents who work in isolated git worktrees, execute concurrently, self-verify with tests, and integrate via git merge. CAID improves accuracy over single-agent baselines by 26.7% absolute on paper reproduction tasks (PaperBench) and 14.3% on the Python library development tasks (Commit0). The key insight is that isolation plus explicit integration beats both single-agent scaling and naive multi-agent approaches. For long-horizon software engineering tasks, multi-agent coordination using git-native primitives should be the default strategy, not a fallback.

How many AI agents should we deploy? The assumption is always "more is better." More agents, more specialization, more parallelism. That's how human teams scale, so it should work for AI teams too. Right? I wanted to test this. So I built AgentCorp: a 12-role AI engineering team running realistic sprint simulations on Amazon Bedrock AgentCore. Each agent is defined in YAML with four things: a role (what they do), a personality (how they think), explicit boundaries (what they cannot touch), and scoped tool access (what they're allowed to use). The Tech Lead reviews architecture but never writes production code. The Security Lead identifies vulnerabilities but never fixes them. Clear lanes, just like a real team. I ran 36 controlled experiments across 3 project complexities with governance harness and phase gates. The result: 5-agent teams outperformed 10-agent teams by 17 to 23% in quality. Across every project type. Then I tested four coordination patterns designed to help: 1/ Coordinator Synthesis: The coordinator reads all research findings and writes a detailed spec before delegating. No more "implement the feature" without context. Every delegation includes file paths, acceptance criteria, and verification steps. 2/ Shared Scratchpad: A persistent directory where agents write durable decisions: architecture choices, API contracts, blockers, completed work. Every agent checks the scratchpad before making decisions that affect others. 3/ Self-Contained Prompts: Every worker prompt includes the full context it needs: why this work matters, what files to touch, what success looks like, and how to verify. No "as we discussed earlier" shortcuts. 4/ Skeptical Memory: Agents treat stored knowledge as hypothesis, not fact. Before building on something from memory, they verify it against actual code. If memory contradicts reality, they update memory immediately. Every single pattern reduced quality compared to baseline. The reason is what I call the Context Consolidation Paradox. A single agent holds the entire project in its context window. No information loss. No coordination overhead. The moment you split that context across multiple agents, you're compressing your project understanding. Every delegation drops signal. This maps to Amdahl's Law. If more than half your work is serial (architecture decisions, integration, review), adding agents adds overhead without proportional gain. Three things I'd tell any technical leader deploying agents today: 1/ Right-size before you scale. Start with 3 to 5 agents. Measure before adding. 2/ Watch your coordinators. If they're forwarding tasks without synthesizing context, your team will underperform. 3/ Trade peak performance for predictability. The structured patterns reduced variance by 79% even while lowering the mean. In production, consistency beats occasional brilliance. We're open-sourcing the full framework and experiment data soon. Stay tuned. #AgenticAI #MultiAgent #BuildInPublic

I spent 102+ hours last week building and delivering a multi-agent system for Microsoft's Global Hackathon, and I wish I had this guide earlier. Here's the framework I took away for repeated success. 1. Start with the "Why" Focus on the core business value. Agentic systems are a powerful tool, but they aren't a silver bullet. ↳Pinpoint the user problem: What is the exact pain point you are solving? ↳Validate the need: Is an agentic system truly the 𝘣𝘦𝘴𝘵 solution 2. Blueprint Before Building I created a high-level, visual architecture of the entire system before diving in, and ↳ Clarified the workflow: Forcing me to think through every single step, from input to final output. ↳ Defined data needs: Helping me immediately identify the required data sources and categories. ↳ Exposed roadblocks early: Allowing plan trade-offs upfront. 3. Know Your Stacksss (yes multiple) In an enterprise setting, security, infrastructure, and resource constraints will dictate your choices. ↳ Understand the approved tools and security protocols you 𝘮𝘶𝘴𝘵 work within. ↳ Identify alternatives: I mapped out three potential tech stacks. ↳ My chosen stack hit roadblocks, but its flexibility meant I could adapt without starting over. Phew! 4. You Can't Outrun Unprepared Data It’s tempting to just dump all your wikis and specs into a RAG pipeline, but this will not scale. ↳ Humans vs. LLMs: Enterprise documentation is written for humans, who can connect the dots across multiple resources. LLMs can't. ↳ I spent two full days manually curating my knowledge base. Deleted 50 low-quality documents, created 10 highly specific, LLM-ready files. 5. Strive for Determinism Enterprise systems demand reliable, repeatable outcomes. ↳ Bridge the gap: Intent mapping to translate natural language into specific function calls. ↳ Build tools: For outputs that required a very specific format, I built deterministic scripts to act as tools for the agent and worked backwards from code to natural language. 6. The Multi-Agent Trade-Off Understand the real costs. ↳ If a single, well-designed agent can solve the problem, stick with that. ↳ The trade-offs are real: Multi-agent systems add complexity in debugging, communication overhead, and operational cost. 7. Build One Agent at a Time ↳ Focus on a single agent. Finalize its prompt, define its inputs/outputs, and test every possible scenario in isolation. ↳ After each agent works on its own, begin connecting them into a cohesive system. 8. Simplify, Then Scale Don't try to solve for every possible case on day one. ↳ Pick one small, highly targeted slice of your bigger scenario. ↳ Build for one, perfectly: Design the entire system to solve that single use case correctly. Expand from that stable, proven foundation. P.S. I used the Azure AI Foundry (azure/ai-agents and azure/ai-projects sdk), and I can't recommend it enough for enterprise-level systems! ♻️ Repost this to help your network upskill

There are three patterns for Multi-agent architectures that are more likely to deliver results in real-world applications today Understanding how multi-agent systems work together is important. Most people focus on what individual AIs can do, not how they collaborate. The architecture you select decides if your system provides value or turns into a costly failure. 🔹 1. Hierarchical systems are similar to team product launches. A central leader assigns specific tasks to different agents, such as market research, content creation, scheduling, and design. Then, it brings their results together into a unified product. This method works well when you have complex tasks with clear boundaries and dependencies. 🔹 2. Human-in-the-Loop systems pause for human insight at critical points. When an AI agent spots a client issue, it writes a response but needs human approval before sending it. This isn't about the limits of AI; it’s about knowing when human judgment is essential in important situations. 🔹 3. Sequential architectures function like assembly lines. Each agent performs a specific task before passing it along. Support tickets go through distinct stages, including initial draft creation, history review, solution development, and CRM logging. Each agent uses its skill without overlap or confusion. The key decision is to match your architecture to the complexity of the workflow and your comfort with risk. Use sequential for standard processes, hierarchical for complex coordination, and human-in-the-loop for critical decisions. Your choice of architecture affects whether multi-agent systems boost productivity or create coordination problems. #aiagents

I was speaking to my team-mate the other day about the increased demand for adaptive, distributed AI solutions and how it has made agentic (multi-agent) architectures a powerful paradigm for scalable automation and intelligent software. She went through the proven steps for designing a robust multi-agent AI system and show how she uses GitHub Copilot to accelerate every stage, from ideation to deployment. What is “Agentic AI”? An agentic system is one where multiple AI-powered agents have distinct responsibilities and can collaborate, coordinate, or negotiate to solve tasks. Imagine a team of specialized automated processes, each optimizing a particular function within a larger workflow. Building Your Multi-Agent Foundation: Define Individual Agents: Each agent should focus on a specific purpose, such as “Natural Language Processing,” “Data Enrichment,” or “Decision Logic.” Partitioning responsibilities helps with modularity, maintainability, and scaling. Choose a Communication Method: Agents must share information efficiently. For solutions hosted on Azure, consider Azure Service Bus or Azure Event Grid for message passing. GitHub workflows can also trigger or coordinate agent interactions. As an alternative, simple async function calls or open-source tools can be used when appropriate. Orchestrate and Coordinate: Use an orchestrator or controller agent to manage workflows and coordinate agent responsibilities. This can be a custom service, an Azure Function, or orchestration logic in a GitHub Actions workflow. Iterate & Collaborate on GitHub: Leverage GitHub Copilot for rapid prototyping, Copilot Chat for in-context code assistance, and GitHub’s built-in code reviews. Automated test generation and inline documentation features further strengthen team velocity and code quality. Monitor & Scale: Implement monitoring and observability with native tools like Azure Monitor and Azure Application Insights for metrics, logging, and end-to-end visibility. For continuous integration and deployment, use GitHub Actions. Open source monitoring can optionally be added for highly specialized scenarios. Why use GitHub Copilot and Microsoft AI for Multi-Agent Systems? - Rapid Prototyping: Eliminate repetitive code. Copilot predicts structure and APIs, focusing your energy on core architecture. - Improved Code Quality: Flag errors early and iterate quickly. - End-to-End Integration: GitHub and Azure ecosystem tools streamline deployment, monitoring, and security from one platform. - Collaborative Development: Accelerate onboarding and documentation. Quickly adapt new agent patterns using Copilot and GitHub project tools. TLDR: By combining modular agent design, robust Microsoft and GitHub powered communication and orchestration, and disciplined engineering, you can achieve scalable, maintainable, and efficient AI systems. GitHub Copilot and the Microsoft stack unlock new levels of team productivity and solution reliability.

Lessons from Building Multi-Agent Systems in Production Here's what's keeping practitioners up at night: 🎯 Key Challenge: We're treating LLM applications like traditional microservices. This is fundamentally wrong. These systems need to be managed as ML artifacts with proper evaluation, versioning, and monitoring. Real-world observations from the trenches: • Data drift is killing us: Data content changes? Your RAG system needs automated re-evaluation. Yet most teams only discover issues through user complaints. • Prompt versioning isn't optional: Moving prompts from code files to versioned systems should be table stakes. But we're still seeing widespread resistance to this basic practice. • Multi-agent architectures demand new paradigms: When you're building domain-specific agents for health insurance, pet insurance, etc., traditional microservice patterns break down fast. My controversial take: Waiting for cloud providers to "solve" LLMOps is a mistake. The community will always innovate faster than any single vendor. What's Working: 1. Treating agents as artifacts with proper registries 2. Building evaluation into CI/CD from day one 3. Implementing automated testing for data, model, AND prompt changes 4. Creating clear separation between agent logic and backend services The path forward isn't more tools - it's better architectures and practices.

The demo looked perfect. Six weeks of work. Clean interface. Fast responses. Then production hit. The agent broke. Not the code. Not the model. The architecture. Because choosing how an AI agent works matters more than making it work. Most teams pick architecture like picking lunch. Whatever feels right. Whatever shipped fastest. Monolithic agents because they're simple. Multi-agent systems because they sound advanced. RAG pipelines because someone read a blog post. Nobody asks the hard question. What does this business actually need? One team watched their customer service agent collapse under load. Built as one massive system. Handling queries. Managing context. Routing decisions. Updating databases. Volume doubled, response times tripled. Edge cases appeared, the system froze. Updates needed, everything went dark. The architecture couldn't bend. So it broke. Another team went the opposite direction. Specialized agents for everything. One for intake. One for routing. One for analysis. One for validation. One for responses. Coordination became the nightmare. Context got lost between handoffs. Simple tasks took five agent calls. Flexible. But impossibly slow. Architecture isn't about following trends. It's about matching structure to reality. The right architecture comes from different questions: ➟ How complex are the tasks? ➟ How fast must responses be? ➟ How much control do humans need? ➟ How often does the system update? ➟ How much context needs to persist? ➟ How many external systems need integration? Three patterns for real applications: Monolithic when: Tasks are predictable and narrow. Speed beats flexibility. Updates are rare. Multi-agent when: Tasks vary in complexity. Different steps need different expertise. Parts scale independently. Hybrid when: Core logic needs stability. Edge cases need flexibility. Tasks run at different speeds. The broken monolith team rebuilt. Core agent handled standard queries. Specialists caught complex cases. Router decided the path. Response times dropped. Scaling became possible. Updates stopped breaking everything. The too-many-agents team simplified. Merged overlapping roles. Cut unnecessary handoffs. Built shared context storage. Performance improved. Maintenance became manageable. Users got faster answers. Both teams learned the same lesson. Architecture decisions make or break AI agents. Not during demos. During production. The best architecture isn't the newest. Or the most sophisticated. It's the one that fits what the business actually does. Because when architecture matches reality, agents don't just work. They scale. The critical question before building: Is the architecture being chosen or just copied? 🔄 Repost if architecture broke your AI agent. ➡️ Follow Aditya for production-ready AI agent insights.