I built a team of AI agents that work together 24/7

A walk through the live setup. The written tour, and the design reasoning behind it, are below.

The team

Every agent here has one job, and the jobs are the kind a person would recognise on an org chart:

• Aurelius — team lead. The one most conversation goes through. Rather than picking the right specialist each time, you tell the lead what you need and it delegates.
• AgentFather — makes the other agents. Creates new agents and modifies existing ones. It is how the rest of this team came to exist; the Salesforce tutorial shows it building one from a conversation.
• Sales, marketing, solutions, customer success. Four specialists, one per function — the solutions and customer-success agents framed as team leads in their own right.
• Security. Its own agent, because security review is a distinct job and not a footnote on somebody else's.
• Email. Everything read or sent goes through one agent that owns the mail connection. One place to look when you want to know what went out.
• Browser control. An agent that navigates pages and clicks, for the work that has no API.
• Grants research. A narrow agent watching for Singapore grant opportunities — a good example of a job too small to justify a person and too specific to forget about.
• A connector agent. Wired into an integration platform that in turn reaches calendar, mail and other tools, which is a reasonable way to cover a long tail of services without a bespoke connection for each.

There are also retired and test agents sitting alongside the working ones — one disabled, a couple used for trying things out. Worth saying, because a real setup accumulates those and it is not untidiness. An agent you have switched off costs nothing and is there when the job comes back.

Why a team lead changes the experience

The single most useful structural choice here is having one agent you talk to. Without it, you carry the org chart in your head — deciding which specialist owns a request before you can make it, which is exactly the overhead you were trying to remove.

With a lead, you describe the outcome and it works out who does what. The specialists still exist, still have their own memory and their own tools, and still do the actual work. You just stop being the router.

The daily task that earns the setup

This is the part that makes it a team rather than a collection of chat windows. A scheduled task runs daily acquisition research, and it goes well past finding names:

1. Research companies that could plausibly be customers.
2. Call a skill written for this exact job — an outreach-draft procedure, authored once and reused every run.
3. Visit each company's website and work out what they actually sell and how they serve customers.
4. Draft a proposal specific to that company, including an illustrative example of how a customer conversation with their own AI assistant would go — grounded in their products and services.
5. Leave the drafts waiting for review.

Each morning the drafts are there: read them, change what needs changing, send the ones that are right. The research, the reading, the first draft — the part that takes the hours — is done. The judgement is still yours, and it is applied at the point where it matters.

Note what the skill is doing. It is not a prompt retyped each time; it is a procedure captured once so every run follows it the same way. That is the difference between an agent that is occasionally useful and one that is dependable.

Watching them talk to each other

There is a view for agent-to-agent communication, and it is more useful than it sounds. Open it and you see the lead agent asking the email agent to prepare the drafts — the actual handoff, in the actual words.

That answers the question you cannot otherwise answer about a multi-agent setup: is this a team, or is one agent quietly doing everything? If only one node ever speaks, you have not built a team yet — you have built one agent with extra steps, and the fix is usually that the specialists were never given distinct enough jobs.

How to structure your own

Two collaboration shapes exist, and picking the wrong one means rebuilding later:

• A peer is a separate top-level agent with its own page, channels and memory. One agent messages another and waits for a reply. Use a peer when the other party has its own responsibilities and its own ongoing context — the email agent above is a peer.
• A subagent is a specialist nested inside one parent. The parent hands off a task, the subagent runs in its own context and reports back, and the parent's conversation stays clean. Use one when the work is a step inside somebody else's job — research this company, draft this section.

Placement is set on each agent's Talk to Agent tab: choose a manager, choose reports and co-workers, and let messaging permissions generate from the org chart. One caution worth internalising — visibility is not permission. Telling an agent that a colleague exists is a separate setting from allowing it to message them, and it defaults to telling them about nobody. An agent aware of a dozen colleagues will try to involve them, and a team where everyone can call everyone produces loops and duplicated work.

The full reference is Teams and delegation.

What makes it 24/7

Two things, and neither is the agents being clever. Scheduled tasks mean work happens on a clock rather than when you remember to ask. Inbound events — a message, a webhook — mean work also starts when something happens. The deployment runs continuously in its own environment, so none of this depends on a laptop being open.

The approval boundary is what makes unattended work comfortable rather than alarming. Overnight output is drafted and queued; anything leaving the building waits for a person. You wake up to decisions, not to actions already taken.

Three things worth knowing before you build one

• Start from a starter team. The catalog ships teams — a manager plus its specialists — alongside individual specialists. Installing one and reshaping it beats designing on a blank page.
• Give each agent a job you could write on a business card. If you cannot, it is two agents, or it is a subagent of something else.
• Add an agent when a job is distinct, not when it is big. More agents are more supervision, not more capacity. The reason to split is clarity.