Who owns the factory

An agent can open a pull request without anyone knowing who will replace its expired credential. Before a team relies on that workflow, decide who maintains it and what happens when it is unavailable.

Assign the work that automation does not remove#

Someone still chooses which tasks the factory may take, maintains the runtime and tools, and reviews changes to shared instructions. Someone answers questions that need a person’s decision. Automation can reduce other work without removing these responsibilities.

Start by recording three areas. Product responsibility covers the factory’s purpose, eligible work and expansion. Maintenance covers workers, credentials, instructions and checks. Response covers failed tasks, unanswered questions, stopping and recovery. These areas can share people; they do not require three separate teams.

Keep ownership of the affected application visible too. The team responsible for a service still needs to understand and maintain accepted changes. For a critical AI-written area, a bounded code-comprehension audit can test whether that knowledge extends beyond the Git author. A factory maintainer cannot make a new business rule on that team’s behalf merely because an agent requested an answer.

For each responsibility, record the decision or action involved, the accountable team, a working contact route and a backup. A maintained on-call rotation can identify the current responder; the table does not need to hardcode one permanent name. Check that the recipient has the authority and access to act.

Distinguish a factory fault from a product fault. A broken worker image belongs with the factory maintainer. A production defect in the application goes through that service’s incident route. If an agent caused the defect, restoring the product and stopping related factory work may both be necessary.

Decide who can stop, approve and expand the work#

Name who may use the stop control and who may resume work. The responder needs a way to stop further actions without asking the failing agent to cooperate. When no responder is available, define whether the workflow waits, limits itself to non-consequential work or does not run.

Record who approves new repositories, data sources and external writes. An instruction update must not quietly grant additional authority. Use the appropriate risk or data specialist for decisions outside the maintainer’s remit.

Set responsibility for spending and capacity as well. Someone must be able to lower a budget or pause new tasks when the review queue is full. An alert sent to a mailbox nobody watches is not an operating control.

Plan the work the factory creates for developers: preparing requests, answering questions, reviewing proposals and correcting defects. Measure that effort before calling more generated code a productivity gain. Review may become a constraint, but it is not automatically the only one.

Separately decide who may access workflow measurements and how long they are retained. Do not let a dashboard’s default view turn a process evaluation into a ranking of individuals. Involve the affected people and the responsible specialists before changing that purpose.

Match support to what stops when the factory fails#

Consider an illustrative pilot that adds advisory comments to pull requests. Reviewers can continue normally when it stops, so stated business-hours support may be enough. If the same tool later becomes a required merge check, its failure now blocks delivery. Revisit the support arrangement at that point.

Write down supported hours, what remains usable during a failure, the approved alternative and where unresolved problems go. Include what happens to queued and active tasks. A fallback should state which checks or approvals replace the unavailable step, not merely say “bypass it”.

Google’s service-level-objectives chapter explains setting expectations around behaviour users need. Its on-call chapter discusses coverage appropriate to a system’s criticality and development stage. Choose support for the impact of an outage, not just because the system is called a platform.

Users can build a dependency without anyone changing the official label. More teams adopt the tool, the manual route is rarely used and nobody knows whether it still works. Review support when adoption grows, permissions change or a workflow becomes part of the required release process.

An alternative also has a capacity limit. Two reviewers may handle one manually reviewed change during an outage, not the whole week’s automated output. State what work pauses and which urgent tasks take priority.

Test the contact route and the manual fallback#

Test with a harmless failed task. Confirm that the report reaches the expected responder, that the backup route works and that the person can inspect the saved code and results. A correct address is not enough when the recipient cannot access the diagnostic records.

Practise stopping a run and denying further writes. Then inspect outstanding external operations before resuming. A worker may have sent a request whose response never arrived; restarting it must not blindly repeat that action.

Exercise the manual path too. Can a developer recover the branch, run the required checks and complete review without the factory? Preserve required approval rules rather than removing them simply because an automation is unavailable.

Shared instructions need maintenance after the pilot. Two edits can introduce contradictory rules about retries or permissions. Give changes to the harness and its instructions a reviewer, evaluation cases and a known version to restore when they cause a regression.

Keep the ownership record small enough to maintain and review it when people or dependencies change. One working route with a backup is more useful than an elaborate table whose contacts are no longer correct.

A small advisory agent does not need the operating model of a production release system. It does need a clear purpose, a responsible maintainer and a way to stop. Add the other arrangements as the work requires them. That makes the people in the factory’s overall process reachable when a decision or failure actually occurs.

Questions people also ask

4 QUESTIONS

▸ Does every factory role need a different person?

No. A small team can combine responsibilities. Make the work, decision authority and backup clear, and keep any required separation of approval and implementation. You do not need seven new job titles to run one advisory agent.

▸ Does a factory need round-the-clock support?

Not automatically. A pilot with a tested manual alternative may be suitable for business-hours support. A required release step has different consequences when it fails. Define support hours, how tasks wait outside them and what users may do instead.

▸ Who responds when the runner fails?

Someone responsible for the factory infrastructure and equipped to restore it. A product incident still belongs with the affected service's response team. When a factory failure affects a product, connect both routes instead of sending people between queues.

▸ What should be decided before extending a pilot?

Check who approves the new task types, data access, permissions and spending. Confirm that reviewers and responders can handle the added work, then test stopping and recovery. More users or more consequential actions may require a different support arrangement.