13 AI Agents as a Team: Auto-Prospect Clients, But Humans Approve Every Send

A developer shared on Reddit how they built a multi-agent system for Olano AI — a real-world sales prospecting workflow that demonstrates a pragmatic approach to multi-agent collaboration. This isn't another vague "AI agents are the future" manifesto. It's a complete pipeline that runs automatically every morning at 7:30 AM and hands control back to humans at critical decision points.

13 Agents, Each with a Clear Role

The system currently has 13 active agents, each with a well-defined role — much like a real company team:

• Aurelius: Team lead
• Maria: Marketing
• Sally: Sales
• Soledad: Solutions
• Sebas: Security
• Curtis: Customer success
• Grantie: Handles grants and opportunity information for Singapore
• AgentFather: Creates and manages the entire agent team
• Composio, Zoho Email, Navi: Tool and integration agents

AgentFather is especially worth noting as a "meta-agent" — it doesn't do the hands-on work itself, but instead organizes and manages the other agents. This kind of layered "agents managing agents" design is a common pattern as multi-agent systems scale up.

A Multi-Agent System (MAS) is an architecture where multiple AI agents — each capable of independently perceiving its environment, making decisions, and communicating with others — collaborate to complete complex tasks. Compared to a single large model, MAS excels at "divide and conquer": breaking a complex task into subtasks handled by agents customized through dedicated system prompts, each maintaining its own independent context window. This avoids attention dilution or context overflow that can occur when a single model is overloaded. The concept of a "meta-agent" like AgentFather draws from metaprogramming — a program responsible for generating and managing other programs. In the LLM era, meta-agents typically hold the full permissions needed to create new agents, including defining their roles, tool access scopes, and communication protocols. This allows the system to dynamically expand the team at runtime without requiring manual changes to the architecture.

The Prospecting Workflow That Runs Every Morning at 7:30

The developer described a scheduled workflow that triggers daily, walking through a complete sales lead generation process:

1. Find 3–5 companies with clear workflow problems
2. Collect public evidence to support those findings
3. Verify publicly available contact information for those companies
4. Bring in the marketing and sales agents for their input
5. Prepare a personalized Zoho email draft
6. Stop and wait for human approval

Throughout the pipeline, agents can communicate with each other and pull in other specialist agents as needed. For example, the sales agent drafting an email can call on the marketing agent to refine messaging and positioning. This "summon an expert on demand" collaboration model is much closer to how a real team operates than forcing a single large model to handle everything.

The Core Experiment: Balancing Autonomy and Control

The developer explicitly states that what this system is really exploring is the balance between autonomy and control.

The principle is clear: let agents do the valuable work themselves, but any action with real consequences must go through a human decision. So in this pipeline, no email is ever sent automatically — all outbound output stops at the draft stage, leaving the final "send" button to a person.

This actually pinpoints a key pain point in deploying AI agents in production. Fully autonomous agents sound great, but once they involve external communications, financial operations, or irreversible actions, the cost of a mistake can be devastating. Placing a human approval gate at the final step is a relatively safe compromise for production environments: AI handles the research, verification, and drafting to boost efficiency, while the ultimate judgment stays in human hands.

The Human-in-the-Loop (HITL) concept is a critical component of AI system safety design — it means forcing human judgment into key nodes of an automated pipeline to prevent irreversible errors from propagating. Where you place the HITL gate involves clear engineering trade-offs: intervening too early undercuts the benefits of automation, while intervening too late allows errors to accumulate beyond recovery. In the AI agent space, safety research from organizations like OpenAI and Anthropic consistently recommends that any action with "real-world side effects" — such as sending communications, executing payments, or modifying production data — should have a HITL node. This is exactly why the system requires human triggering for the seemingly simple act of sending an email: once sent, it's extremely costly to recall and can damage customer relationships, making it a textbook irreversible action.

Real Engineering Questions Posed to the Community

Rather than showing this off as a finished product, the developer posed several substantive engineering questions to others building multi-agent systems:

• How should agents communicate? Should there be a single manager agent for centralized orchestration, or peer-to-peer delegation?
• Where should the human approval gate go? Too early slows things down; too late and things can spiral out of control.
• In production, how much autonomy do you actually give your agents?

These questions sit right at the heart of multi-agent architecture design. The manager agent pattern makes orchestration and accountability easier to track but can become a bottleneck. Peer-to-peer delegation is more flexible but harder to debug and keep consistent. In this system, the presence of both Aurelius as team lead and AgentFather clearly leans toward the manager pattern — while still preserving the ability for agents to pull each other in collaboratively, making it something of a hybrid approach.

The Orchestrator/Manager Pattern and Peer-to-Peer Delegation are the two dominant communication topology paradigms in multi-agent systems. In the manager pattern, a central orchestrator agent handles task decomposition, dispatches instructions, and aggregates results — similar to an API gateway in a microservices architecture. It offers clear call chains and easy log tracing and error isolation, but the manager itself becomes a single point of failure and concentrates reasoning costs. In peer-to-peer delegation, agents can call each other directly, resembling an event-driven architecture with greater flexibility — but consistency guarantees and protection against circular calls (preventing A→B→A infinite loops) are significant engineering challenges. Major agent frameworks today (such as LangGraph, AutoGen, and CrewAI) offer varying levels of support for both patterns, and developers need to choose the right topology based on task coupling and fault tolerance requirements.

What This Means for Builders

The value of this case study isn't the number of agents (13), but the replicable production paradigm it offers:

Use anthropomorphized role assignments to keep system responsibilities clear. Use a meta-agent to manage team complexity. Use scheduled triggers for continuous unattended output. And use human approval gates to lock down risk exposure.

For teams pushing AI agents into real business workflows, the lesson that "AI does the first 90%, humans make the final 10% of critical decisions" is far more worth borrowing than chasing 100% automation.

The developer has also expressed willingness to share more details on architecture, memory mechanisms, approval design, and tool integration. Developers interested in the topic can find plenty of transferable design ideas in this Olano AI implementation.