Build a unified memory (knowledge graph or an LLM wiki) and serve it over MCP servers or skills, so any agent, open or closed, plugs in within minutes.
That distinction helps. In clinical AI, memory without the business-logic layer can become an archive the team still has to interpret.
Around an OR, the context layer would need to classify what it carries: read-only background, state that changes setup, or an exception that needs a named human owner. Otherwise the system remembers a lot, but the workflow still cannot tell what is allowed to move.
Not in a deployed clinical setting, so I would keep the claim at the design-pattern level.
But yes, an append-only log feels like the right primitive for the parts that should be preserved rather than edited away: source trusted, state changed, uncertainty left open, owner assigned, and why the next action was allowed or stopped.
The clinical risk is treating the log as memory alone. It also needs a policy layer that decides which entries can move workflow state.
Exactly. That separation is the useful part: the append-only log preserves what happened, while the materialized view decides what a given workflow is allowed to act on now.
For clinical AI, that would let the same case history support different views: coaching, readiness, quality review, escalation. The hard gate is making sure no view silently upgrades old context into current authority.
Yes, that is the part that makes it useful beyond memory. For an OR-adjacent system, the same log entry might feed different views: setup gaps, handoff receipt, and a learning view that preserves uncertainty without turning every signal into a score. The policy layer is where those views stay honest.
In a clinical workflow, the log should probably stay boring and append-only, while the views become role-specific: what a learner needs for feedback, what a team member needs to confirm, what a surgeon needs to own, and what should never move state without escalation.
The danger is letting a filtered view look like the whole truth.
That multiple-view point is the useful distinction. In a clinical workflow, the same append-only record should not feed every surface the same way: room-readiness, audit, and coaching views need different policies.
The log preserves what happened. The view decides what is allowed to shape the next action.
Thanks for the article and interesting read much needed one in the proliferation of harnesses. Do you have any course or procedure around how to go about building one or the one you built
Yea I have already enrolled for your course with towardsai. Interesting and enjoying. I believe it was about the research and writing multi-agent workflow system. I was interested in the decoupling of context layer and harnesses that you discussed here - Pretty powerful and look forward to see if it is covered in your book or any short workshop
Unfortunately, I don't have any open-source course on this topic yet. I have one upcoming on building a coding agent from scratch.
But my book will be 100% on this topic, showing how to build a unified memory for a personal assistant from scratch: with MCP servers, graphRAG, fine-tuning, and the whole gang
The portability point maps cleanly to clinical AI. Around an OR, the context layer would need to preserve case state rather than just memory: which source was trusted, what changed since the last case, what uncertainty stayed open, and which human owns the exception. If that layer moves cleanly across models or harnesses, the workflow boundary stays inspectable instead of being rebuilt with each tool.
That distinction helps. In clinical AI, memory without the business-logic layer can become an archive the team still has to interpret.
Around an OR, the context layer would need to classify what it carries: read-only background, state that changes setup, or an exception that needs a named human owner. Otherwise the system remembers a lot, but the workflow still cannot tell what is allowed to move.
Great additions!
You can power your memory with an append-only log, which, by its nature, is read-only to solve these issues. Have you tried it?
Not in a deployed clinical setting, so I would keep the claim at the design-pattern level.
But yes, an append-only log feels like the right primitive for the parts that should be preserved rather than edited away: source trusted, state changed, uncertainty left open, owner assigned, and why the next action was allowed or stopped.
The clinical risk is treating the log as memory alone. It also needs a policy layer that decides which entries can move workflow state.
100%
but the beutify of the append only log is that between the log and the materialized view you can apply any filter/policy at runtime
or even create multiple views with different policies. Beutiful and powerful
Exactly. That separation is the useful part: the append-only log preserves what happened, while the materialized view decides what a given workflow is allowed to act on now.
For clinical AI, that would let the same case history support different views: coaching, readiness, quality review, escalation. The hard gate is making sure no view silently upgrades old context into current authority.
Yes, that is the part that makes it useful beyond memory. For an OR-adjacent system, the same log entry might feed different views: setup gaps, handoff receipt, and a learning view that preserves uncertainty without turning every signal into a score. The policy layer is where those views stay honest.
That separation is the useful part to me.
In a clinical workflow, the log should probably stay boring and append-only, while the views become role-specific: what a learner needs for feedback, what a team member needs to confirm, what a surgeon needs to own, and what should never move state without escalation.
The danger is letting a filtered view look like the whole truth.
That multiple-view point is the useful distinction. In a clinical workflow, the same append-only record should not feed every surface the same way: room-readiness, audit, and coaching views need different policies.
The log preserves what happened. The view decides what is allowed to shape the next action.
Thanks for the article and interesting read much needed one in the proliferation of harnesses. Do you have any course or procedure around how to go about building one or the one you built
Thanks, Karthik!
Yes, I do have a course with 35 lessons on building something similar: https://academy.towardsai.net/courses/agent-engineering?ref=b3ab31
And working on a book teaching this exact same thing (but it will get released with Manning within their MEAP program only in ~4 months or so)
Or you can find a bunch of free stuff around AI Engineering starting here: https://www.decodingai.com/p/ai-engineering-roadmaps-courses-and-books
Yea I have already enrolled for your course with towardsai. Interesting and enjoying. I believe it was about the research and writing multi-agent workflow system. I was interested in the decoupling of context layer and harnesses that you discussed here - Pretty powerful and look forward to see if it is covered in your book or any short workshop
That's great to hear, Karthik.
Unfortunately, I don't have any open-source course on this topic yet. I have one upcoming on building a coding agent from scratch.
But my book will be 100% on this topic, showing how to build a unified memory for a personal assistant from scratch: with MCP servers, graphRAG, fine-tuning, and the whole gang
Thanks, Look forward to the book Paul !!
Thanks 🥂
The portability point maps cleanly to clinical AI. Around an OR, the context layer would need to preserve case state rather than just memory: which source was trusted, what changed since the last case, what uncertainty stayed open, and which human owns the exception. If that layer moves cleanly across models or harnesses, the workflow boundary stays inspectable instead of being rebuilt with each tool.
Exactly! You got it right. The context layer contains the memory layer + the business logic and serving layer you just described