Share the workflow.
Name the responsibilities.
Build your model orchestration with skills for the job and built-in MCIR memory for relevant history. Give sources, routing, tools, and memory boundaries named owners, so continuity never becomes unrestricted access.
No invisible change to an important path.
The practices below belong in your repository, ticketing process, and application. They are not a promise of built-in approvals or live co-editing.01who owns what
Different questions need different reviewers.
- Workflow maintainer
- Owns the route and configuration. Checks that a reachable model, the intended per-model skills, and required policy bindings remain on the chosen path.
- Knowledge owner
- Approves source documents and revisions. Resolves conflicting guidance, corrects stale remembered context, and decides when a source should no longer be used.
- Application engineer
- Owns permissions, tool argument validation, error handling, and the human-review experience. Separates draft generation from external side effects.
- Operational reviewer
- Knows whether the result is fit for its actual purpose. Can reject the draft, request missing evidence, or escalate beyond the workflow.
02an authored review specimen
Make the change smaller than the review.
Route equipment-return questions to a source-backed draft.
Review the route, not just the nicest output.
A short successful draft can hide a broader permission, an unrelated source, or a policy that was never bound. Review what changed in the configuration and what the negative fixtures now do.
Record the intended model capability, source revision, tool scope, policy identity, and owner alongside the change. A version label is useful only if it points to the configuration actually used.
The record shown here is a suggested working document. It is not an exported theo schema, a built-in audit receipt, or an importable recipe.
03a repeatable practice
Propose. Inspect. Approve. Observe.
- 01Propose
Describe one behavior change and the sources, keys, or tools it affects.
- 02Inspect
Replay synthetic positive and negative cases. Compare the path, not only the answer.
- 03Approve
The appropriate owners review the evidence in your existing change process.
- 04Observe
Check deployed behavior, handle errors, and keep a known restore point.
04configuration is not consent
Shared does not mean universally enforced.
Does shared work mean everyone shares all memory?
No. MCIR is scoped to the authenticated user, account, or organization owner, not a global pool. Keep identity and resource permissions explicit when deploying agents or connecting another application. Cross-session continuity does not merge tenants or grant access.
Does this page describe built-in team approvals?
No. The roles, review record, and revision discipline are an operating practice for your team to implement with its existing tools. They do not imply built-in co-editing, sign-off queues, deployment branches, or source-control integration.
Can we replace human review with a guardrail?
Not for the responsibilities described here. A configured rule evaluates particular patterns or constraints; it does not determine whether a business, clinical, or legal decision is appropriate.
What should we test after changing a policy binding?
Check the real API key, policy status, phases and verdicts, plus the bound and unbound cases. Test tool denial, missing context, and the output behavior your client displays. A green browser simulation is not production enforcement evidence.
Review a workflow together without sharing real data.
Use a synthetic recipe as a common reference. Record what should happen when context is missing, a tool is denied, or a policy is unbound.