Start with the work.
Then connect the pieces.
Your models, skills, and connected tools, with MCIR memory built in. Carry relevant decisions and context into the next task, agent, or application. These three patterns keep the sources, permissions, and human handoff visible.
What can this workflow prepare, and who may act on it?
Illustrative patterns. Not customer stories, deployed integrations, or performance claims.01choose a starting point
Three patterns. Different responsibilities.
Connect your EHR. Give theo a skill.
Your team builds the connection. A custom skill brings the permitted tool, your knowledge, and your instructions together. theo prepares; your people review.
healthcare workflows- Input
- Permitted records from your team's EHR or system integration.
- Context / route
- A read-only tool, your checklist, and a custom skill.
- Draft
- A source-linked draft with unresolved items ready for human review.
- Human owner
- Your application controls access and release. People retain clinical and coverage decisions.
Answer from the right record.
An internal operations answer should reflect the current policy, not the most confident sentence. Keep source identity and unresolved questions beside the response.
company knowledge- Input
- A request to explain a fictional equipment return process.
- Context / route
- Use an approved policy excerpt, not unrestricted company search.
- Draft
- A short answer and a proposed, non-executed follow-up task.
- Human owner
- The process owner resolves exceptions and authorizes any action.
Make changes reviewable.
A shared workflow needs a shared understanding of what changed. Treat sources, routing, skills, and policy bindings as configuration that deserves review.
team workflow practice- Input
- A proposed change to a team's request-routing recipe.
- Context / route
- Compare the intended route, source revision, and bound policy.
- Draft
- A review record with positive, negative, and missing-context fixtures.
- Human owner
- Named maintainers test and approve changes in their own process.
02the common structure
The model is a step, not the whole workflow.
- 01Define the input
State the task, allowed data, and intended recipient before supplying context.
- 02Choose the path
Combine current sources with relevant owner-scoped memory, choose models, and verify any policy binding.
- 03Prepare the draft
Keep source references, uncertainty, and incomplete fields visible.
- 04Review in your app
A responsible person decides whether to edit, reject, or release the result.
03before you deploy
Make the boundary part of the brief.
Choose one bounded task before connecting a broad collection of tools. Specify which documents may enter, which actions are read-only, which changes require approval, and what the system should do when a source is missing.
Gateway Guardrails are opt-in and bound per API key. Adding a policy to a diagram or writing a reassuring prompt does not establish enforcement. Inspect the real binding, test its behavior, and keep tool authorization in the application.
For healthcare or other sensitive work, review the deployment, agreements, data recipients, and operating procedures before using real records. A synthetic example cannot establish clinical suitability or compliance.
build the next layer
Follow the part you need to understand.
Built-in MCIR memory recalls relevant facts, preferences, decisions, and open questions within the same owner scope.
Separate an explicit policy binding from an intention written in a prompt.
Connect the API, handle errors, and keep permissions and review in your own product.
Try changing one assumption.
Remove a source or deny a mock tool in the browser-only workbench. Follow the changed result before thinking about a production integration.