Five agents with real boundaries

The problem with one assistant

A single general-purpose agent gives you confident answers in domains it has no business answering. Ask it to price an offer and it will cheerfully produce a number with no grasp of margin. Ask it whether a prospective client is safe to take on and it will tell you, without knowing that it should not be the one deciding.

The failure is not capability. It is that nothing owns anything, so nothing can be relied upon — which is the same failure as an operations team with no named owners.

Lively: a strategy-and-execution team

• Bruce — marketing strategy. Channels, audiences, creative, content, SEO, paid media, offer construction.
• Marcus — sales and revenue operations. Pricing, margin, unit economics, pipeline, forecasting, retention.
• Jarvis — executive assistant. Inbox, scheduling, briefings, and hands-on operation of the CRM, task and document systems.

Three agents whose domains genuinely overlap, which is why the routing rules are the real design. A user's question rarely announces which agent it belongs to, so the boundaries are written down as a shared vocabulary, resolved once:

• An offer's price or margin goes to Marcus. The same offer's hook and creative goes to Bruce.
• “Funnel” as a campaign question is Bruce. As a forecast question, Marcus.
• CRM: whether the data can be trusted is Marcus. Performing the cleanup is Jarvis.
• Deciding what should happen is Bruce or Marcus. Doing it in a system is Jarvis.

Underneath them sits a shared memory: a standardised knowledge base per client brand — brand, audience, voice, offers, channels, campaigns, performance, competitors, economics, pipeline, sales process, decisions and learnings. Fourteen files, the same shape for every account, so someone who has never touched an account gets a real answer in one prompt rather than a plausible one. Prompts are easy to copy. Accumulated client intelligence in a consistent shape is not.

ARC IP Law: research agents

• Tony — due diligence on prospective clients and their strategic partners, before a commitment is made rather than after.
• Troy — research on referral partners and networking opportunities, so calendar time goes to rooms worth being in.

Diligence for a law firm is the clearest case for hard boundaries, because a wrong answer is not merely unhelpful. Tony is built around four rules:

• Confirm identity before attributing anything. Name collisions are the most common way diligence goes wrong, and the most damaging — adverse information pinned to the wrong person.
• Keep verified fact apart from allegation. Primary and official sources first; anything adverse stays an allegation until a reliable source establishes it.
• Classify, and say what the classification cannot tell you. A Green, Yellow or Red rating — with the explicit caveat that finding nothing is not proof of no risk.
• Escalate judgement to an attorney. Tony never states that conflicts are clear, because conflicts are a separate process, and never makes the final decision on whether to accept a client. Legal judgement calls go to a person whose job that is.

The detailed procedures load only when a task needs them, so the core instructions stay short enough to follow reliably.

The principle both share

Each agent is told what to decline, not only what to do. Jarvis executes; he does not set strategy. Bruce does not touch pricing. Tony researches and recommends; he never clears conflicts or accepts a client.

That refusal is what makes the answers trustworthy. An agent that answers everything tells you nothing about whether this particular answer is any good — and in a law firm, an agent that oversteps can create a problem a person then has to unwind.

How it gets maintained

Each agent has one canonical definition, versioned in a single place, with build scripts that generate the paste-ready instructions and packaged skill bundles from it. Updating an agent is one edit and a rebuild, rather than a message asking everyone to re-copy something.

Which is the same idea as every other system here: write it down once, give it an owner, and make the next use a configuration rather than a rebuild.