An answer is useful.
An accountable handoff is better.
Connect a business question to the right source, models, and owner. Built-in MCIR memory carries relevant preferences, decisions, and open questions forward, so the next task does not start from nothing.
01fictional operations desk
“How do I return a loaned device?”
This is a made-up internal knowledge example. The policy, document revision, and task below are synthetic, not customer data or a shipped connector.
Return instructions for review
The sample equipment policy says to contact the operations desk before returning a loaned device. The desk confirms the return method. [POL-07 · r3]
There is no approved destination in the supplied excerpt, so this draft does not provide an address or shipping label.
Proposed next step: prepare an internal follow-up task for the operations owner. Do not submit it until the owner reviews the request.
Approved excerpt
POL-07 · r3: “For a loaned-device return, ask the operations desk to confirm the return method.” Only this fictional excerpt is available.
Missing authority
No shipping address, exception policy, or permission to change a device record has been provided.
02from knowledge to action
Separate finding an answer from acting on it.
- 01Question
Receive a request about a defined process, without unnecessary personal data.
- 02Approved context
Use the current source revision and relevant owner-scoped memory, then choose a capability for the task.
- 03Draft + proposal
Return an answer with a source label and a proposed follow-up, not a completed action.
- 04Owner decision
Review the destination, permissions, and intended change before executing anything.
03the smallest useful tool
Give a tool less authority than a person.
{
"example": "not an API payload",
"tool": "prepare_return_task",
"source": "POL-07 · r3",
"destination": "operations-review",
"write_permission": false,
"status": "proposed",
"required_reviewer": "process owner"
}A description is not an authorization check.
Tool definitions describe actions a model may request. Your executor must still validate arguments, check the caller and resource scope, constrain the destination, and reject unauthorized side effects.
For this example, start with a read-only source lookup and a draft task. A separate application action can require owner approval before a real write. Do not let a generated tool name or a sentence saying “approved” grant authority.
read the integration guide04the operating agreement
Write down what happens when the answer is incomplete.
- Source owner
- Maintains the approved source set and revision. A stale or inaccessible policy produces a visible gap, not an invented substitute.
- Memory scope
- MCIR keeps useful context within the authenticated user, account, or organization scope. Carry the relevant history into agents and connected apps, not across tenants or beyond the caller’s permissions.
- Configuration owner
- Reviews routes, model choices, per-model skills, and any bound policies. An enabled but broken orchestrator path should surface a configuration error, not quietly use an unrelated model.
- Application owner
- Implements authentication, resource permissions, review gates, permitted tool recipients, and error handling. Those responsibilities do not move into a prompt.
- Process owner
- Accepts or rejects the draft, handles exceptions, and decides whether the proposed action may happen. Keeps a correction path for people affected by it.
Choose one question your team already owns.
Model the source, draft, and review boundary first. Use the workbench to inspect a synthetic path before connecting any business system.