Why a back office beats a lone agent

A useful agent back office makes work easier to follow. It gives incoming requests a place to land, assigns responsibility, and keeps preparation separate from actions that affect customers, systems, or money. You can begin with a document and a few named responsibilities. A dashboard is optional.

This series uses CJS's internal agent documents as an attributed case study. CJS describes Secretary as its front desk, Optima as lead coordinator, and Infrastructure as responsible for servers and deployments. Its product agents include Apex Researcher, Apex Content Developer, and Apex UX. These are documented CJS roles, not a requirement to copy its organization exactly.

The design exercises below are teaching examples derived from those patterns. They are not instructions to operate CJS systems. Work on paper or in a local draft throughout these public parts.

Where a single conversation becomes difficult

Consider this invented practice request: “Improve our course introduction and get it ready for learners.” The wording combines several jobs. Someone must understand the desired improvement, check factual claims, revise the text, assess the presentation, and decide whether the result can go live.

A capable assistant may perform several of those preparation steps. The difficulty is remembering which steps actually happened. A fluent final answer can conceal missing evidence: perhaps the text was edited but the claims were never checked, or a local preview was mistaken for a live release.

A back office gives these transitions names. A draft can be ready for review without being approved for publication. A reviewer can flag a problem without becoming responsible for fixing the server. A coordinator can assign work without granting permission for every possible action that work might imply.

This matters even with one human and one assistant. Separate responsibilities reduce ambiguity when the conversation resumes tomorrow, when another tool contributes a draft, or when the human changes the scope halfway through.

Four responsibilities worth separating

The CJS sources offer a practical starting point:

These responsibilities solve different problems. Intake preserves the request. Coordination resolves ownership. Specialist work produces an artifact or finding. Visibility helps the team see progress and blockers.

CJS's internal Secretary instructions are especially clear: Secretary never does the work itself. Its task is to route requests and work the review queue. That boundary prevents the front desk from quietly becoming an all-purpose operator with unclear authority.

Your local design can be smaller. Write “intake,” “coordinator,” and “worker” beside three sections in a document. Assign one person or assistant to each responsibility. If the same assistant fills multiple roles, record each handoff explicitly rather than treating a change in role as permission to act.

Ownership makes a handoff useful

“Someone should check this” leaves work floating. “Research owns checking the two claims in this draft and will return sources plus unresolved questions” gives the next person a concrete assignment.

For a local practice workflow, a useful handoff contains:

• The requested outcome and the current scope.
• A named owner for the next step.
• The draft, evidence, or other material to inspect.
• A clear description of what completion means.
• Any action that remains outside the assignment.

This is a teaching template, not a CJS database specification. Its purpose is to make missing information visible. A named owner cannot work effectively if the request has no source material or if “done” means something different to each participant.

For the course introduction example, completion might mean “an edited local draft with factual questions marked.” That is a useful deliverable. It does not imply that the text was published, sent to learners, or deployed to a website.

Keep consequential actions behind a decision

CJS calls certain categories “never-JEV” in its intake rules. For this series, use never act alone as the practical lesson: an automated routing result must not make the final decision on these actions. Secretary escalates these items to Optima or the owner and must not reroute them itself.

The full list is:

• Money: payments, prices, refunds, and similar financial changes.
• DNS, infrastructure, and deploys: domains, servers, firewalls, configuration, and releases.
• Sending: email, social messages, Slack messages, or other outbound communication.
• Publishing: making content available to an audience.
• Deletion: removing data or other material.
• Access: roles, permissions, and user accounts.

The boundary concerns what the request would do. A friendly tone, a familiar sender, or a confident classification does not remove the stakes. Preparing a refund explanation differs from issuing a refund. Drafting a message differs from sending it.

In your own office, name the authorized decision maker and the specialist who may execute the approved action. Do not assume that naming a specialist grants approval. In the CJS pattern, Infrastructure owns deployment work, while Secretary escalates infrastructure requests. Those responsibilities coexist.

Visibility should describe evidence

CJS's internal reporting guide asks agents to report working, idle, or blocked and to report real state only. Its Office status document describes a staff dashboard with stations such as copy-desk, qa, front-desk, server-room, and deploy-pad. The Office floor is not public.

The useful idea is that status should explain work rather than decorate it. “Working on introduction: checking the draft against the supplied sources” tells the coordinator something actionable. “Blocked: source needed for the enrollment claim” identifies the missing input. “Everything looks great” does neither.

Keep the distinction between activity and outcome. Writing a draft is activity with an artifact. Verifying a claim is a finding supported by evidence. Publishing is an external action. A good update says which one occurred.

You do not need to recreate the Office floor to learn this habit. A local note with owner, current task, and blocker can provide enough visibility for a small project. Never invent activity merely to make the office look busy.

A small office in practice

Return to the course introduction request. In a written simulation, intake records the desired result and flags publication as a consequential action. Coordination assigns the content preparation step. Research checks the factual material, content revises the draft, and UX may assess how the introduction reads in context if that review is in scope.

CJS's internal Codex guide describes a related division of labor: Codex can help with heavy drafting, the Researcher verifies primary sources, and the Content Developer edits and provides the final content gate. Codex never deploys. This offers a useful example of a helper contributing substantial work without owning every downstream decision.

At the end of your simulation, there should be a reviewable artifact and a clear next owner. If publication or deployment is still pending, say so. A successful preparation task can end with a handoff.

Quiz

Q1. In the CJS case study, what does Secretary do with incoming requests?

• It completes simple requests itself so the queue stays short.
• It routes requests and works the review queue, but never does the work itself.
• It approves consequential actions once a route is confident.
• It deploys approved changes on behalf of Infrastructure.

Q2. A routing rule confidently classifies a request to change user permissions. What should happen?

• The change can proceed, because a confident classification counts as approval.
• The request should be deleted, because access changes are never allowed.
• It still needs an authorized decision, because access is on the never-act-alone list.
• The router should reroute it until a worker accepts it.

Q3. Which status update best follows the "report real state only" habit?

• "Everything looks great."
• "Working hard on several things."
• "Live," posted as soon as the draft is written.
• "Blocked: source needed for the enrollment claim."

Sources and attribution

This lesson draws on CJS's internal agent documents, shared with Apex Academy for this case study: the agents README (team and Infrastructure remit), the Secretary instructions (intake and escalation), the Office reporting guide (truthful status), the Office status document (staff visibility and stations) and the Codex helper guide (drafting, verification, content review and the deployment boundary). These documents are not publicly available. Exercises and handoff templates are Apex Academy teaching adaptations.