Benmore and Agent Factory: an FDE reading path
Twelve paired reading sessions connect Forward Deployed and AI Agent Factory to discovery, specifications, evaluation, recovery, and customer ownership.
Read with a concrete decision to make. Close the source, recall the idea, then build the artifact. These prompts are an independent synthesis; the original Benmore PDF is not hosted.
1. Understand the job
What are you responsible for after the demo?
Start with a person’s task and a result they can verify. Use AI to help execute the work while retaining responsibility for the decision, the evidence, and the operating relationship.
Keep this distinction: Benmore describes its consulting practice. Agent Factory focuses on AI workers. FDE roles can also involve conventional software and data systems. Neither book defines every employer’s role.
Benmore: Chapter 1, Compressed Like a DJ, printed pages 2–8; Chapter 11, What is Forward Deployed?, printed pages 72–75; Chapter 12, The Deployed Workflow, printed pages 75–77.
Recall: Explain the difference between the human FDE and an AI worker without using either acronym.
Build: Responsibility map
- Customer problem and daily user
- What I own: discovery, delivery, adoption, operations
- What needs another specialist or decision owner
- One outcome and how we will observe it
Apply this in the learning guide
2. Discover before promising
Which part of the brief is still a guess?
Treat a polished request as the beginning of an investigation. Replay recent work with its operator. Separate observed behavior, reported needs, and assumptions before agreeing a delivery date.
Keep this distinction: A sponsor’s preferred solution contains useful context, but it is not proof of feasibility. A generated requirement does not become a fact because it appears in several documents.
Benmore: Chapter 2, Disco Debt, printed pages 8–14; Chapter 3, Yes, Yes! Yes if…, printed pages 14–17; Chapter 4, What Discovery Actually Is, printed pages 18–23; Chapter 5, Understanding the Client, printed pages 23–32.
Recall: Name one observation that would make you change your proposed solution.
Build: Evidence ledger
- Claim and source
- Observed, reported, or assumed
- Impact if wrong
- Owner and next verification step
Apply this in the learning guide
3. Make a conditional commitment
What can you deliver within the real constraints?
Choose a small outcome with a baseline, a test, and an owner. Compare ordinary automation with a model call before committing to an agent. Make access dependencies and stop conditions visible.
Keep this distinction: Respectful challenge protects the relationship. Treat Benmore’s escalation and separation advice as one firm’s practice; follow the actual engagement’s authority and agreements.
Benmore: Chapter 3, Yes, Yes! Yes if…, printed pages 14–17; Chapter 6, The Relationship, printed pages 32–35; Chapter 7, The Discovery Process, printed pages 36–50; Chapter 8, Walking Away, printed pages 51–56.
Recall: If access arrives two weeks late, what changes: scope, date, or the decision to continue?
Build: Pilot brief
- User, baseline, and desired outcome
- Included work and explicit non-goals
- Access, time, and budget assumptions
- Acceptance owner and pause condition
Apply this in the learning guide
4. Write intent that can be tested
Could someone build the wrong thing and still pass?
Connect project intent to a feature, then to a small implementation task and its acceptance examples. Update both the specification and the checks when new evidence changes the plan.
Keep this distinction: A complete-looking specification can preserve a wrong assumption. Review the intent with the operator as well as checking the resulting code.
Benmore: Chapter 7, The Discovery Process, printed pages 36–50; Chapter 9, General Trends in AI-Driven Development, printed pages 57–62.
Recall: Close the document. Describe one required behavior and the exact observation that proves it.
Build: Behavior specification
- Input and required output
- Rules, permissions, and denied actions
- Happy path and two failure examples
- Links to evidence and changed decisions
Apply this in the learning guide
5. Decide who owns each step
What should change, and what must still be protected?
Study the current workflow to understand it, then redesign around the outcome. Keep obligations and useful controls; challenge repeated handoffs and data entry. Assign responsibility at each consequential step.
Keep this distinction: Copying an old workflow can preserve waste. Removing a step without understanding its purpose can remove a necessary control. Resolve uncertainty with the accountable operator.
Benmore: Chapter 4, What Discovery Actually Is, printed pages 18–23; Chapter 5, Understanding the Client, printed pages 23–32; Chapter 7, The Discovery Process, printed pages 36–50.
Recall: Why is “a human will review it” an incomplete control?
Build: Delegation map
- Step and purpose
- Keep, change, or remove, with evidence
- Human, AI, or collaboration, with reason
- Reviewer, check, timing, and review date
Apply this in the learning guide
6. Give every answer a source
Is this a rule, a live fact, or someone’s interpretation?
Bring together approved knowledge, current operational facts, and relevant case notes. Preserve source identity, version, access boundaries, and missing evidence when assembling context for a task.
Keep this distinction: Search relevance does not establish authority. A model’s memory, an indexed copy, or a chat comment cannot silently replace the system or expert that owns the answer.
Benmore: Chapter 7, The Discovery Process, printed pages 36–50.
Recall: What should happen when a helpful note conflicts with an approved procedure?
Build: Context packet
- Task, actor, and allowed action
- Applicable rule, version, owner, and citation
- Live facts from the owning system
- Supporting notes, conflicts, and missing evidence
Apply this in the learning guide
7. Use the prototype to learn
What looks finished but is still simulated?
Use a working slice to test the flow with a person. Keep a gap register that distinguishes demonstrated behavior, placeholders, missing integrations, and release evidence.
Keep this distinction: Benmore’s prototype percentages are illustrative, not acceptance targets. Start security and permission checks with implementation; a later readiness review does not replace them.
Benmore: Chapter 9, General Trends in AI-Driven Development, printed pages 57–62; Chapter 10, An AI-Driven Development Process, printed pages 63–71.
Recall: Show one prototype behavior you would not yet expose to a real user, and explain why.
Build: Release-gap register
- Requirement and current behavior
- Mock or incomplete dependency
- Risk, owner, and evidence needed
- Pilot exclusion or closure decision
Apply this in the learning guide
8. Prove the result and the checker
Which wrong answer still earns a passing grade?
Compare a simple baseline with the proposed workflow on held-out tasks. Inspect the resulting state and failure groups. Check a model grader against independent labels before using its score to decide on release.
Keep this distinction: A deterministic test proves a bounded property; an evaluation describes sampled behavior. A high average can hide a serious failure in a small but important group.
Benmore: Chapter 10, An AI-Driven Development Process, printed pages 63–71.
Recall: Give an example where the response sounds correct but the task actually failed.
Build: Evaluation decision
- Baseline and held-out cases
- Expected and actual final state
- False passes, false failures, and serious errors
- Release decision, limitations, and reviewer
Apply this in the learning guide
9. Design approval and recovery
Can the operator understand, change, and recover the action?
Place the proposed change, evidence, and alternatives at the decision point. Show where work is waiting and who can act. Practise a wrong recommendation and an interrupted operation through the interface.
Keep this distinction: Correct model output does not guarantee usable software. Measure the attention and corrections the complete workflow demands from people.
Benmore: Chapter 7, The Discovery Process, printed pages 36–50; Chapter 10, An AI-Driven Development Process, printed pages 63–71; Chapter 13, Knowledge Transfer and Graduation, printed pages 77–81.
Recall: What information must be visible before a reviewer approves an assignment?
Build: Supervision brief
- Action preview and supporting evidence
- Approve, edit, reject, and stale-decision behavior
- Pending, failed, and completed states
- Recovery path and keyboard-only task result
Apply this in the learning guide
10. Turn repeated work into a worker
What replaces the help you give during a session?
Promote a proven recurring task by making its specification, checks, escalation rules, and runtime durable. Give jobs identity, bounded execution, persistent state, and an accountable operator.
Keep this distinction: A successful session is useful evidence, but it does not establish unattended reliability. Keep the simpler workflow if repetition and value do not justify operating a worker.
Benmore: Chapter 10, An AI-Driven Development Process, printed pages 63–71; Chapter 14, The Support Phase, printed pages 82; Chapter 17, Support in the AI Era, printed pages 88–90.
Recall: If the worker stops after a remote write succeeds, how does the next run avoid repeating it?
Build: Worker operating contract
- Trigger, job ID, and durable state
- Allowed actions, runtime, and retry limits
- Escalation reason, recipient, and evidence
- Pause, restart, and duplicate-trigger demonstration
Apply this in the learning guide
11. Transfer the ability to operate
Could another person fix and change the system?
Prepare a runbook for incidents, a system overview for design decisions, and a maintained specification. Ask the receiver to recover a failure and make a small change using those assets.
Keep this distinction: Documentation delivery is not the same as knowledge transfer. Choose technology and operating practices that the receiving team can maintain.
Benmore: Chapter 11, What is Forward Deployed?, printed pages 72–75; Chapter 12, The Deployed Workflow, printed pages 75–77; Chapter 13, Knowledge Transfer and Graduation, printed pages 77–81.
Recall: Which step did the receiver need you to explain, and what did you change afterward?
Build: Witnessed handoff
- Primary and backup owner
- Runbook, system overview, and current specification
- Recovery and change drill results
- Unresolved issues and accepted responsibilities
Apply this in the learning guide
12. Agree what happens after delivery
Where does support end and new work begin?
Match support to actual operating needs. Separate maintaining agreed behavior from new scope, name response ownership, and set a review point. Reuse only the assets you have the right to reuse.
Keep this distinction: Benmore’s support percentage is its commercial example, not a market rate. Agent Factory’s vertical business model is an option, not a requirement for employment or a promise of earnings.
Benmore: Chapter 14, The Support Phase, printed pages 82; Chapter 15, The Support Model, printed pages 82–85; Chapter 16, When to Recommend What, printed pages 86–87; Chapter 17, Support in the AI Era, printed pages 88–90.
Recall: When would the honest recommendation be no additional support contract?
Build: Support and reuse agreement
- Coverage, hours, escalation, and exclusions
- Maintenance versus new scope
- Operating owner and next review date
- Reusable asset, ownership, and customer-data boundary