AI ENGINEERING WORKFORCE: HOW THE WORK IS ORGANISED Work architected at Fifth9 Engineering practice — The diagram represents an engineering practice and its controls. It does not claim a universally autonomous delivery service. This is an operating approach around engineering, not another platform successor. It separates work planning, implementation, independent review and completion decisions. The product architecture describes what is being built; the workforce approach describes how contributors work on it. How do multiple AI contributors become a team whose work can be understood? Coordinate AI-assisted engineering so responsibility, review and the meaning of completion remain understandable. Separate work areas and explicit responsibilities reduce accidental interference when contributors work concurrently. Coordination is still needed around genuine dependencies and shared decisions; more simultaneous activity does not guarantee that more useful work finishes. BUILDING BLOCKS Work planning Give contributions clear scope and ownership. Receives: Goals, dependencies and acceptance expectations. Produces: Tasks with a defined purpose and responsible contributor. Separate work areas Reduce collisions between concurrent contributions. Receives: Assigned tasks and shared-code constraints. Produces: Bounded areas in which contributors can work. Implementation Produce a change and the checks relevant to it. Receives: The task, source context and constraints. Produces: A proposed change with supporting observations. Independent review Examine the change separately from its author’s completion claim. Receives: The change, acceptance expectations and evidence. Produces: Findings and a review disposition. Completion and learning Record what is ready and what remains unresolved. Receives: Review results, checks and the intended outcome. Produces: A clear completion decision and useful follow-up lessons. WALKTHROUGH 1. Define useful work Choose a bounded contribution and its acceptance conditions. Express the intended result and how it will be examined. A well-scoped task gives both the contributor and reviewer a shared question without dictating every implementation detail. 2. Assign and coordinate Allocate responsibilities and identify dependencies before parallel work creates collisions. Separate work areas reduce interference, but shared decisions still need explicit coordination. 3. Build and check Implement the change and run checks that address its behaviour. Report incomplete paths and failures, so the next reviewer can inspect the actual result rather than infer success from activity. 4. Review separately Challenge the result before treating it as complete. Have a different review perspective examine the proposed change and supporting evidence. Questions about correctness, scope and useful completion should not be answered solely by repeating the author’s account. 5. Close with context Record the outcome, unresolved issues, remaining dependencies and lessons for later work. Closing an item should make its contribution understandable; process activity by itself is not a measure of value delivered. ILLUSTRATIVE EXAMPLE — Bring concurrent contributions together Several agents are contributing to the same application. Tasks are divided to reduce overlapping edits. Each proposed change is checked and reviewed separately. The coordinator can see which contributions are ready, which need revision and which depend on another task. If two contributions conflict or a dependency is unresolved, the coordinator needs to sequence the work or return it for revision. A completion statement alone does not settle the conflict. An understandable view of what changed, what is ready and what remains dependent. An explanatory operating model; agent activity or repository volume alone does not measure delivered value. Why these responsibilities are separate The author, reviewer and person deciding completion answer different questions. Implementation proposes a change, review examines it, and completion connects it to the intended outcome and remaining conditions. This operating practice supports the systems being built; it is not another version of the platform. SCOPE Separated implementation and audit sessions, coordinated workspaces and explicit completion decisions. Automated checks supporting the people directing delivery. REMAINING QUESTIONS Can another person understand why an item is considered done? Where do handovers or shared dependencies cause rework? Which improvements to the operating method increase useful outcomes? BOUNDARIES AND EVALUATION Useful completion: More activity is not the same as more useful completed work. Evaluation: Assess completed changes against the objective, including rework and unresolved dependencies. Separate review: A contributor’s statement of completion is not an independent review. Evaluation: Check that the review examines the proposed result rather than repeating the author’s summary. Coordination under failure: Workspace and workflow controls still depend on judgement and correct operation. Evaluation: Exercise conflict, interruption and unclear ownership cases and examine how responsibility is restored. The aim is greater delivery capacity with a clear account of what changed, why it matters and what is ready to use. AI Initiative — public architecture guide.