CUSTOMER ACCOUNT / ATTRIBUTED EVIDENCE
What this case establishes
This is a commercial publisher’s customer account. Roseram checked the source and wrote the analysis; it did not interview the customer, run the product, audit the figures or establish that AI caused the reported business result. The pilot below is a proposal, not a completed experiment.
Primary material reviewed 2026-10-12. Analysis and proposed evaluation by Roseram Editorial.- 01Ticket and constraints
- 02Bounded agent work
- 03Reviewed pull request
Factory: the documented workflow
Anthropic’s Factory account describes Droids for review, documentation and coding tasks, including taking a ticket and returning a pull request. It attributes aggregate engineering time and cycle improvements to customer deployments. The story references a historical model configuration; those examples are not proof of current behavior on an arbitrary repository.
The mechanism worth examining
Delegation becomes useful when the returned artifact can be accepted without rediscovering the original intent. A ticket alone often omits compatibility, data ownership and release constraints. Provide the issue, relevant source, an acceptance contract and the permitted tools as a single package. The agent can then plan and act within that boundary. A pull request is a handoff artifact, however, not an automatic declaration that the requested feature is complete.
The implementation decision
Start with maintenance work whose result has an existing oracle: a dependency upgrade with a test matrix, a documentation correction tied to source or a narrow refactor with preserved behavior. Avoid delegating an underspecified migration merely because it looks repetitive. Define who will review the result and which external actions require approval. The budget should include supervision, failed attempts and the verification needed before the task rejoins normal delivery.
Where the workflow can fail
An agent can complete local tests while missing a service dependency, runtime flag or production data shape. It can also broaden the task to fix unrelated issues, making the review harder. Require a scope ledger explaining each changed file. Test what happens when credentials or essential source are unavailable. A sensible failure response should preserve the work and identify the missing decision instead of silently substituting a guessed implementation.
A practical evaluation, designed for this use case
Choose several historical tickets with known acceptance results. Give the agent bounded branch access and approved commands, then compare returned patches with the ticket contract. Record completed, blocked and rejected tasks separately. Review the tool trace for unauthorized scope expansion. The learning goal is to identify a class of work that can be delegated reliably with your supervision requirements, rather than to declare that software engineering as a whole has become autonomous.
Primary sources
Figures and product details above are dated and attributed; they are not current guarantees.
- Anthropic: Factory primary account ↗The attributed workflow and reported result. Proposed pilots and decisions below are original Roseram analysis.
The decision matrix
Original evaluation criteria for this workflow. These are questions to test, not results measured by Roseram.
| Decision | Evidence to collect | Stop or revise when |
|---|---|---|
| Ticket readiness | Acceptance contract and dependencies known | The task relies on unwritten assumptions |
| Execution authority | Approved branch and commands | The agent attempts an external write beyond scope |
| Handoff quality | Patch and evidence are reviewable | A pull request is presented as proof of delivery |
YOUR EVALUATION / NOT A REPORTED RESULT
A small pilot you can inspect
Use these steps as a planning checklist. Checking a box records your progress in this view; it does not run or validate an experiment.
Questions this case answers
Is creating a pull request the same as finishing the ticket?
No. Review, acceptance checks and the release process determine whether the artifact fulfills the task.
Why use historical tickets?
Known outcomes make it easier to see whether an agent found the real requirement or merely produced a plausible alternative.
Tools & capabilities referenced
Operators studying this story often evaluate adjacent AI products. Explore Roseram guides where available:
PRACTICAL NEXT STEPS
Take the evidence into your own project.
Calculate the whole project cost
Compare subscriptions, usage, launch work and renewals.
Test an existing-project workflow
Check import, source loading, preview and publication.
Verify the output you buy
Require evidence tied to a real customer task.
Wiki brief
Factory is examined here for delegating bounded engineering tasks. The article answers “What does an engineering agent need to complete a ticket responsibly?” using linked primary material and original evaluation design. It is not a customer testimonial for Roseram or an endorsement by Factory.
Operator takeaways
- Delegate with an acceptance contract.
- Keep execution authority explicit.
- Separate artifact creation from task acceptance.
Related case studies
Plan → build → review with routed models and transparent usage.