Create a Specialist Agent Only After Its Work Boundary Is Stable

Adding an agent is easy. Giving it a durable job is harder.

The useful rule is: create a specialist only when its work boundary is stable enough to write down, review, and reuse. Until then, keep the work with a main agent and improve the shared project guidance.

This is where APC and APX have different jobs. APC is the portable layer: it keeps a project's shared rules, structured agent definitions, reusable skills, and safe curated context in the repository. APX is the runtime layer: it makes those agents useful in daily work through conversations, tools, routines, and local state. A runtime can start an agent immediately; that does not make the agent design ready to travel.

A role is not a label

A weak specialist is only a name: researcher, writer, or support. It sounds organized, but it does not tell another person—or another runtime—what the agent owns, what it must consult, or where it must stop.

A stronger role has a boundary. Consider a support workflow:

• The agent handles first responses and routine refund triage.
• It uses the project's refund policy and escalation skill.
• It escalates large refunds rather than approving them.
• It writes in the project's customer-facing language.

That is a contract, not a personality. It can live in an APC agent definition and linked skills, be reviewed in a pull request, and be read by compatible tooling after a fresh checkout.

Start with one repeated decision

Do not split work because a team diagram looks better with more nodes. Split it when one decision pattern keeps returning and has clear inputs, constraints, and handoff conditions.

For example, a main agent may initially answer support questions, check policy, and call for human review when needed. After that pattern is repeated, the project can extract a support specialist. The extraction should preserve the decision boundary:

Inputs: customer request and account context
Rules: published refund window and escalation threshold
Output: response, or a clearly named escalation
Not owned: legal negotiation or approval beyond the threshold

This small shape prevents a common mistake: creating a specialist that overlaps every other agent and silently makes choices outside its intended role.

Put durable detail in the right place

APC gives the boundary a portable home:

• AGENTS.md holds project-wide rules.
• .apc/agents/<name>.md states the specialist's role and instructions.
• .apc/skills/ holds reusable procedures shared by one or more agents.
• .apc/ excludes raw conversations, credentials, and runtime caches.

APX can then use that contract while keeping the daily machinery local: sessions, messages, private runtime memory, provider credentials, and tool execution belong to the runtime rather than the repository.

That separation matters during change. Updating a support rule is a project decision. It should be visible in the portable contract. A chat transcript from yesterday is runtime evidence, not the new source of policy.

A practical test before adding an agent

Before creating a specialist, write four lines: purpose, inputs, constraints, and handoff. If those lines stay vague, the work is probably still main-agent work. If they are precise, the project has something worth encoding in APC.

Then APX can run the agent in the places people actually work. The runtime gives the role a daily presence; APC keeps the role from becoming a local, unreviewed convenience.

A good specialist is therefore not another prompt to maintain. It is a portable promise about a narrow kind of work.

Comments

[arcwrightai]

Agreed — a fuzzy boundary just makes the agent drift into whatever task is easiest, and then you're debugging scope instead of output.