Person and intention
Define the goal, preferences and limits.
- Receives
- An ambition and chosen limits
- Produces
- A shared understanding of the intended result
AI Initiative · early concept
Quarks: the original concept architecture
An explanation of the original idea for coordinating specialised AI assistance around a person’s goal.
Historical proposal A present-day explanation of the original concept, not a claim of a currently available product.
The design question
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.
A view of the responsibilities
From a goal to coordinated assistance
- 01Define the goalA proposed responsibility
- 02Select useful responsibilitiesA proposed responsibility
- 03Provide bounded contextA proposed responsibility
- 04Coordinate contributionsA proposed responsibility
- 05Review and carry forwardA proposed responsibility
Across the flow
Keep sources, permission, uncertainty and the person’s ability to correct the result visible throughout.
What each part is responsible for
The building blocks
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
Following one piece of work
How the flow fits together
01Define 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.
02Select 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.
03Provide 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.
04Coordinate 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.
05Review 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 · not a benchmark result
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.
The useful result: 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.
Reading the architecture accurately
Scope and status
What the original concept describes
- 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.
What the concept does not establish
- 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.
Where the design must hold up
Boundaries and evaluation
| Boundary | Why it matters | How to examine it |
|---|---|---|
| Role and competence | A role name does not establish competence, reliable collaboration or authority to act. | 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. | 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. | Establish implementation and operating behaviour separately; do not carry original promises of perfect execution or uninterrupted service into current claims. |