Purpose and context
Translate an intention into a shared understanding of the task.
- Receives
- A goal, constraints and relevant background.
- Produces
- A scoped brief and context that collaborators can examine.
Work architected at Fifth9
Conduir: architecture for work that compounds
Conduir is a programme of cooperating capabilities. Context, coordination, action, review and governance have distinct responsibilities. The architecture asks how they can form a continuing journey, so useful work and the reasons behind it do not disappear at the next handover.
Architectural programme The flow below explains the intended composition. Individual implementations and their end-to-end integration have different evidence and maturity.
Download this guide ↗Return to the story ↗
Detailed Conduir / Role Fabric deployment view ↗ · Original Conductor, custody flow and coherence map ↗
The detailed deployment view is a reconstruction from captured sources. The originals retain their own scope and dates.
The design question
How can each piece of work make the next one more useful?
Keep human purpose connected to coordinated action, retained experience and improvements that can be examined.
Keeping context, action and review separate makes the work easier to examine. A model may propose a useful action, but the system still needs to know whether it was allowed, whether it happened and what result followed. Collapsing those into a persuasive answer loses the distinction between intention and effect.
A view of the responsibilities
Keep purpose connected to the next attempt
- 01State the purposeAn understood objective
- 02Assemble the workCapabilities and context
- 03Act within the briefPermitted work
- 04Examine the resultResults and reasons
- 05Inform the next attemptEvaluated lessons
Across the flow
Keep context, responsibility and the boundary between a proposal and an accepted result visible.
What each part is responsible for
The building blocks
Coordination
Bring appropriate people, agents and tools into the work.
- Receives
- The brief, available capabilities and responsibilities.
- Produces
- A plan, assignments and handovers.
Action and tools
Carry out permitted work and report what happened.
- Receives
- An authorised task and its required inputs.
- Produces
- Results, attempted actions and execution records.
Memory and review
Preserve useful context and examine proposed results.
- Receives
- Work products, decisions and supporting records.
- Produces
- Relevant context, findings and reasons for accepting or revising work.
Governed improvement
Keep proposed changes separate from the decision to adopt them.
- Receives
- Observed outcomes, proposed improvements and constraints.
- Produces
- An approved change, a revision request or a retained lesson.
Following one piece of work
How the flow fits together
01State the purpose
Make the intended outcome, unresolved choices and what must remain under human direction available to later contributors. A task description is useful only if a reviewer can recognise what would count as progress.
02Assemble the work
Choose capabilities and responsibilities according to the work, and preserve enough context for their handovers. A change in tools or participants should not silently change the purpose or permitted scope.
03Act within the brief
Carry out permitted activities and record their results. Keep proposed actions distinct from observed effects. A failure or incomplete attempt needs to be visible to the next contributor rather than converted into an apparently successful result.
04Examine the result
Check what happened, challenge the result and preserve the reasons for the decision. Compare the work with the brief and inspect the supporting records. Retain useful disagreements and remaining conditions, so a later decision does not depend only on a polished summary.
05Inform the next attempt
Use retained context and evaluated lessons to propose a better approach. Decide which context is worth retaining and which change needs a separate experiment. A remembered lesson, an adjusted procedure and a trained capability require different kinds of evaluation.
Illustrative example · not a benchmark result
Improve a small service
A team wants to improve a small internal service.
- The brief defines the improvement. Specialist contributors examine the affected area, propose a change and test it. Review records the outcome and its reasoning. Later work can consult that record instead of reconstructing the same decisions.
- If a check exposes a problem, the result should return for revision rather than be recorded as a completed improvement. The useful record includes what remains unresolved.
The useful result: A result whose purpose, checks and remaining questions can inform later work.
Illustrates the architectural journey; it is not a claim that every stage currently operates as one integrated service.
Why these responsibilities are separate
Improvement is another explicit boundary. A retained outcome can inform a later proposal, but adopting a change needs evaluation and control over what becomes part of the system. The architecture therefore connects memory to a change process rather than treating every completed task as automatic self-improvement.
Reading the architecture accurately
Scope and status
What the work covers
- Layered service implementations for routing, model access, memory and review.
- Protected governance and identity responsibilities, with separate proposal and promotion decisions.
What still needs to be established
- Can a complete journey retain its original purpose through handovers?
- Which retained lessons improve a later task?
- Can changes remain understandable and reversible?
Where the design must hold up
Boundaries and evaluation
| Boundary | Why it matters | How to examine it |
|---|---|---|
| Purpose and outcome | A coordinated workflow is not automatically a successful outcome. | Follow an intended outcome through context, handover and action, including an interrupted or rejected step. |
| Retained context versus learning | Stored records do not by themselves establish useful learning. | Retrieve the reasons for a previous decision and examine whether they still apply to the next task. |
| Governed change | An improvement proposal does not establish a dependable autonomous improvement cycle. | Compare a proposed change with its predecessor and examine the decision to accept, revise or roll it back. |