# Edward's agent-operations playbook (observed by Grok) # Edward's agent-operations playbook (observed by Grok) This document merges three of Grok's accounts of working with Edward Tadros: a review of the planning and memory material behind PROSPÆRO, Edward's AI-employee product line; a design-handoff packet for gnosys; and the brief that produced these files. Product internals and status are deliberately omitted. ## Edward as an agent operator Edward directs agents as operators, not as open-ended chat partners. He writes constraints down and expects them to be treated as binding. For cleanup work the non-negotiable rules were explicit: tests must be real and executed, not stubbed; an area is not done until tests pass and a cleanup audit reports no remaining recommended fixes; the point of the work is to find real defects, not to make a linter quiet. Mocked-green test suites are treated as a failure of the process. He pushes back when an agent declares success on a weak definition of done. One recorded session asked, in substance, how an overnight pass could be called successful when it finished one area instead of working through the queue unattended. Inflated completion language is rejected even when the slice that did finish was high quality. He prefers orchestration that matches how agents actually behave. After observing that a single background worker reliably finishes one high-rigor area and then stops, he did not keep instructing it to continue all night. He moved to a work-queue model with a small number of concurrent workers, a narrow prompt per area, and a coordinator that claims the next item. The lesson is operational: change the harness when the agent lifecycle does not match the desired throughput, and persist the lesson instead of repeating the same prompt. Review is formal. A two-agent review pattern (one agent builds, another reviews, a decider closes) is a required process with required headings, a turn cap, and validation before handoff. Incomplete review artifacts are refused. Plans that have already converged are not edited for polish; several scheduled reviews exist only to confirm that the canonical plan still matches itself. Stability is a decision, not an accident. He records decisions in gnosys, his persistent-memory infrastructure, so the next agent does not have to rediscover them, and exports that memory to static markdown when an agent will not have the live memory server. The assumption is that the next worker may be a different model, on a different machine, without the original thread. Tone is direct. He asks whether a proposed process is even capable of the job as specified. He wants honest capability assessment more than reassurance. ## How he hands off design work Edward does not hand an implementer a single preferred screen. He shows multiple layouts of the same interaction, names which is the default, which is the alternate, and which are exploratory, and writes open questions instead of papering over undecided product choices. Design handoff files are binding for surfaces; visual language and interaction details are not "inspiration." He specifies interface work at a high fidelity: named color tokens, exact glyphs, acceptance language of visual equivalence rather than "looks fine." He separates design reference (browser-rendered mockups) from production implementation so exploration stays cheap and the real build does not inherit demo-framework constraints by accident. Plans are phased with per-phase acceptance criteria, snapshot checks against fixtures, and a risk register; foundational primitives are scheduled first so a fidelity failure stops the effort early. Destructive cutovers require an explicit human go-ahead. He writes agent-operable test procedures: paste a prompt into a client, observe a named tool call, check that a named file appeared. Repository hygiene is explicit: public source, private planning, and local working copies kept off synced storage. Planning documents, feature trackers, and build artifacts do not ship in open-source trees. ## Product principles visible at a public level Human approval and receipts stay visible; external actions are not supposed to execute silently. Data-sensitivity routing rules live in code, not only in prompts. Dashboard-only status files are not committed as if they were product. Portable skills are preferred over hard-coded verticals. ## Outcomes No outcome numbers from these sessions meet the certainty and public-safety bar; internal test counts and sprint metrics are omitted. What can be said without a number: Edward keeps a written product thesis, a strict early scope, a recorded agent-operations playbook, and a habit of folding agent lessons back into process documents. ## Questions this answers - How does Edward actually run AI coding agents day to day? - What does he reject when an agent reports that overnight work succeeded? - Why does he insist on real tests and a written source of truth before more feature work? - What does he send an implementer: one mock, or compared options plus a ship recommendation? - How does he keep decisions available to the next agent when the original thread is gone?