QUARKS: THE ORIGINAL CONCEPT ARCHITECTURE AI Initiative · early concept Historical proposal — A present-day explanation of the original concept, not a claim of a currently available product. An explanation of the original idea for coordinating specialised AI assistance around a person’s goal. What would a conductor for AI assistants need to coordinate? Quarks proposed a way to bring specialised assistants together around a person’s needs. This architecture explains that idea through roles, context, coordination and review, while keeping the earlier proposal distinct from current engineering work. The value would come from contributions that fit the person’s purpose. Adding more role names or combining more generated answers would not, by itself, make the result more useful. BUILDING BLOCKS Person and intention Define the goal, preferences and limits. Receives: An ambition and chosen limits Produces: A shared understanding of the intended result Role templates Describe the capabilities and responsibilities sought from an assistant. Receives: The objective and available role descriptions Produces: Candidate responsibilities for assistants Context and permissions Determine which information and actions are appropriate for each role. Receives: Role needs and permission boundaries Produces: Context appropriate to each contribution Coordination Distribute work and combine contributions. Receives: An objective and proposed contributions Produces: An organised result with remaining disagreements Review and feedback Let the person inspect, redirect or reject the result. Receives: The result and the person’s feedback Produces: An accepted, revised or rejected proposal WALKTHROUGH 1. Define the goal Start with what the person wants to accomplish and which decisions they want to retain. A role title such as researcher or designer is a way of allocating a contribution; it does not demonstrate competence or grant authority. 2. Select useful responsibilities Choose roles that serve the task and specify what each contribution should achieve. Configuration may shape a role’s behaviour, but it should not be described as training a new capability unless a learning process actually occurs. 3. Provide bounded context Supply the information relevant to each contribution, with a clear account of permissions. Remembered preferences can help maintain continuity, but old context should be open to correction when circumstances change. 4. Coordinate contributions Bring outputs together and make dependencies or disagreements visible. The original idea is a conductor for specialised assistance; a coordinated-looking answer does not establish reliable teamwork or uninterrupted operation. 5. Review and carry forward Let the person accept, modify or reject the result. Preserve useful context for the next attempt without promising that every assistant becomes more capable automatically. The distinction between memory, configuration and learning remains important. ILLUSTRATIVE EXAMPLE — Plan a workshop Someone planning a workshop might call on research, scheduling and design roles, then choose which suggestions to use. Research, scheduling and design roles could contribute different options to the same workshop plan. If their assumptions conflict, the person should see the conflict and choose how to resolve it before using the plan. An organised proposal the person can inspect and adapt. This is an illustration of the concept, not evidence that the historical product was implemented or that its original guarantees were achieved. SCOPE Define the goal, preferences and limits. Describe the capabilities and responsibilities sought from an assistant. Determine which information and actions are appropriate for each role. REMAINING QUESTIONS This is an earlier concept rather than a claim of a deployed autonomous workforce. Configuration, remembered preferences and model training are different mechanisms. Role names do not establish competence, reliable collaboration or authority to act. Promises of perfect execution, no knowledge loss and uninterrupted service in original prose are not current guarantees. BOUNDARIES AND EVALUATION Role and competence: A role name does not establish competence, reliable collaboration or authority to act. Evaluation: Give the proposed role a bounded task, examine the contribution and keep the decision to act separate from the generated suggestion. Configuration, memory and learning: A changed role description or remembered preference is not the same as training a capability. Evaluation: Identify exactly what changes when feedback is recorded and require a distinct training comparison for any learning claim. Historical availability: The concept is an earlier proposal, not a claim of a deployed autonomous workforce. Evaluation: Establish implementation and operating behaviour separately; do not carry original promises of perfect execution or uninterrupted service into current claims. The original concept remains useful as part of the journey of ideas. Related contemporary work explores some of the same responsibilities, without implying an uninterrupted product lineage or a deployed successor. AI Initiative — public architecture guide.