Roles and ownership

A role becomes useful when it explains what someone owns, what they return, and where their authority ends. A title alone cannot answer those questions. “Content agent,” for example, could mean a draft writer, an editor, a publisher, or all three under different conditions.

Part 1 introduced a back office as a way to separate intake, coordination, specialist work, and visibility. This part makes those responsibilities concrete. The aim is a small ownership map that you can use to review a request before anyone begins work.

CJS's internal agent documents provide the case study. Their role names and stated responsibilities are attributed below. The role cards, exercises, and sample handoffs are teaching adaptations for a local workflow; they do not establish new CJS policy.

Read the CJS role map carefully

CJS's internal sources describe the following responsibilities:

The last row illustrates an important reading habit. The reporting roster establishes the UX agent's identity, but does not by itself define a complete review policy. For your practice project, you may assign UX to assess clarity or presentation. Label that as your proposed scope rather than claiming that the roster specifies it.

Likewise, a station indicates where work belongs in the Office view. It does not grant permission. CJS's internal Office status document associates deploy-pad with releases and server-room with infrastructure. Moving to a station cannot substitute for authorization to release software or change a server.

Separate three kinds of ownership

A request can have a coordinator, a current worker, and an approving decision maker. These may sometimes be the same person, but the responsibilities remain distinct.

The coordinator keeps the request moving, resolves unclear ownership, and notices when the scope changes. The current worker produces the next deliverable. The decision maker authorizes an action that needs approval. An evidence reviewer may supply a verdict that informs the decision without owning every later step.

Suppose a draft contains a factual claim and needs a clearer introduction. Research can own verifying the claim. Content can own revising the introduction after the evidence is available. A publication decision belongs at the defined content gate and within the applicable authorization. Infrastructure remains the deployment specialist where a release is required.

Avoid the phrase “the team owns it” when you need a next step. Shared interest is useful, but one current owner should be able to say what they are returning and to whom. Supporting reviewers can be listed separately.

Write a role card before assigning tools

For the exercise, give each role a short card with five fields:

1. Purpose: the problem this role exists to solve.
2. Inputs: the request, sources, or artifact it needs.
3. Output: the concrete deliverable it returns.
4. Limits: what it cannot decide or execute on its own.
5. Handoff: who receives the result and what they need to know.

Here is a proposed local research card:

Purpose: check the factual claims in a supplied draft. Inputs: the draft and relevant public source material. Output: a claim list with supporting evidence, corrections, and unresolved questions. Limits: no publishing, sending, account changes, or infrastructure work. Handoff: return findings to the content owner; identify anything that prevents a reliable revision.

This card borrows the CJS pattern of Researcher verification. The particular output format is an Academy exercise. That distinction lets you learn from a real office without treating every useful teaching template as an implemented feature.

Define completion so another role can use it

“Finished research” is difficult to assess. “Checked the three claims in the supplied draft; two are supported and one needs removal or a stronger source” tells the next owner what can happen.

A local content assignment could end with an edited draft and a brief change note. A UX assignment could end with a list of readability issues and suggested revisions. A coordination assignment could end with a resolved owner and a documented scope. Each output should fit the question the next role must answer.

Keep work states precise. “Ready for content review” describes a handoff. “Approved for publication” describes a decision. “Live” describes an observed outcome after an external action. None should be inferred solely from the one before it.

CJS's internal reporting guide reinforces this discipline through real-state reporting. An agent can be working, idle, or blocked in that reporting workflow. A blocked report should identify the dependency, such as missing source evidence, rather than imply progress that has not happened.

Keep the never-act-alone list on every role map

CJS intake escalates its never-JEV categories to Optima or the owner. Secretary cannot resolve those items by rerouting them. Use this complete list when drafting your own action limits:

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

This is an approval boundary, not a ban on useful preparation. A worker can draft a proposed message within an authorized writing task. Sending that message is a separate action. A specialist can explain a proposed infrastructure change without applying it.

A role card should name who resolves these boundaries. If the right decision maker is unknown, the request needs clarification through coordination. Do not let tool access answer the ownership question: being able to perform an action does not establish permission to perform it.

Helpers contribute without inheriting authority

CJS's internal Codex guide describes Codex as a helper for heavy jobs, including long drafts, refactors, tests, and bulk content passes. It requires review of that output. In its standing research workflow, the Researcher verifies primary sources and provides the research verdict. In its article workflow, the Content Developer edits and provides the final content gate. Codex never deploys.

The general ownership lesson is that producing a large amount of work does not make a helper the final reviewer. A long draft can still contain unsupported claims. A polished summary can still omit a qualification. The receiving role must inspect the artifact against the actual assignment.

For this local exercise, imagine a helper returns a draft. The content owner checks that it answers the brief, Research checks the claims that require verification, and any unresolved issue remains visible. No helper output should quietly change “prepare a draft” into “send it to customers.” Never place secrets, credentials, or customer data into a helper prompt.

Handle gaps and disagreements explicitly

An ownership map will expose gaps. Research may need a source that was never supplied. Content may discover that the requested wording conflicts with the evidence. UX may suggest a change that expands the original assignment.

In each case, return a concrete question to coordination: what is missing, why it affects the deliverable, and what decision would unblock the next step. Continue independent work that remains within scope where useful. Do not conceal the gap by inventing evidence or expanding permissions.

If two workers both believe they own the same task, have coordination choose the next owner and record which artifact is current. If no one owns the task, leave the assignment unresolved until ownership is established. A visible gap is easier to correct than a false completion claim.

Quiz

Q1. Several roles contribute to one request. How should ownership be recorded?

• Say "the team owns it" so nobody feels left out.
• Name one owner for the current next step, and record reviewers and the decision maker separately.
• Give ownership to whichever role produced the most work.
• Let the coordinator own every step until the request is finished.

Q2. A helper such as Codex returns a long, polished draft. What does that mean for review?

• The helper becomes the final reviewer, because it produced the work.
• The draft can be published if it reads well.
• Only the formatting needs checking, because the content is generated.
• The receiving roles still review it, because producing work does not make a helper the final gate.

Q3. In CJS's Office, an agent moves to the deploy-pad station. What does that establish?

• It has permission to release software.
• It shows where the work belongs, but it grants no permission.
• It means Infrastructure has approved the release.
• It means the release has already gone live.

Sources and attribution

This part draws on CJS's internal agent documents (agents README, Secretary instructions, Office reporting guide, Office status document and Codex helper workflow), shared with Apex Academy for this case study and not publicly available. They support the named roles, escalation boundaries, reporting discipline, stations and review gates. Role cards and sample ownership exercises are Academy adaptations.