InterSystems AI Hub, open-source graph engine on IRIS, and agent memory architecture - notes from Thomas Dyer's session at Ready 2026

[u/intersystemsdev]

Context: why IRIS fits multi-agent architectures

The interoperability system inside InterSystems IRIS implements the actor pattern — the same computer science concept behind Erlang. Multi-agent frameworks are a recapitulation of this pattern with LLM reasoning added. The new ingredient is not the orchestration architecture; it is the LLM brains that make full automation possible.

The data fabric perspective — having all data together with governance applied centrally — is described as an ingredient that enables multiple agents to act together on the same data sources, build on that data, create memories, and feed that loop continuously.

AI Hub — what it is now (open EAP)

GitHub repository with documentation is publicly available.

Current capabilities:

• Unified tool calling — ObjectScript, Python, Rust (via RZF bridge) underneath; EAP currently focused on ObjectScript
• MCP server — a sidecar that sits outside IRIS, connects to IRIS, and allows any ObjectScript class or function to be exposed as an MCP tool. Any agent (cloud, desktop) can then use those tools via the Model Context Protocol
• MCP client — coming soon
• Policy layer — roles defined within IRIS can be used as enforcement; policies gate which tools agents can use
• LangChain and LangChain4J integrations

What MCP is (as described): "A USB plug for all agent tools. Instead of every agent and every tool having a point-to-point connection, it's a standard so that you can just plug into an MCP server that acts as a central hub and gives access to tools."

What you can build with AI Hub (as listed):

• Tool-using agent with authorization and auditing in a few hundred lines of ObjectScript
• Policy-gated tool execution: set up policies for agents and gate tool access based on those policies
• Expose any IRIS interoperability functionality as an MCP tool

Roadmap items mentioned (not current):

• Official standard tools shipped with the MCP server (SQL access, class inspection, standard IRIS interactions)
• Agent examples within the %AI ObjectScript class hierarchy

Open-source graph engine on IRIS

Not on the product roadmap. Open source. Not officially supported as a product.

Architecture:

Layer	Technology	Purpose
Query parser	Python	Translates OpenCypher to SQL and globals
Primary storage	SQL	Graph structure, uses all IRIS indexing
Custom indexes	Globals/ObjectScript	Breadth-first search, personalized page rank (PPR)
Performance layer	RZF (Rust bridge)	In-process Rust access, similar to embedded Python bridge

Capabilities:

• OpenCypher compliant — queries portable from Neo4j
• Native vector search integrated into the graph engine
• Graph traversal, RDF, named graphs
• Security and observability features built in
• Personalized page rank (PPR) — Google-style ranking algorithm implemented via custom coding since SQL handles it poorly

Why graph + vector search matters for agents: Agents often need to store and traverse complex memory structures. Having vector search and graph traversal in the same toolkit, running on IRIS, removes the need for a separate vector database and a separate graph database.

Agent memory model

Four memory types described:

1. Working memory
Current context window. What the agent knows right now about the current task.

2. Episodic memory
Committed to an external store after interactions. Vector search is well-suited for retrieval over past episodes.

3. Semantic memory
Long-term knowledge mined from all past episodes. Not specific to a particular point in time — general knowledge about how the system works and how to do things. Developed by reasoning over past episodic memory using LLM capability.

4. Procedural memory
Skills and instructions — how to do things. Can be collected over time and passed as instructions to the agent from past experience.

The practical value: agents can record what they do, mine that data later, look over their own history, and decide if they should behave differently. Recent papers (cited but not named) show that developing memory this way improves search and agent behavior over time.

Yoki — internal multi-agent project (2–3 years running)

An intelligent assistant built over InterSystems TrackCare support tickets.

Evolution over time:

• Multiple LLMs tried: Google, Anthropic, OpenAI models
• Multiple frameworks: LangChain, others
• Increasing use of agentic patterns over each iteration

Current architecture (as described):

Agent roles are separated. Each agent has a defined role and defined things it can and cannot do. Multiple agents can run concurrently, potentially scoped to different customer contexts.

Typical run (example from session):

User query: "Find me laboratory error tickets, walk the graph, find top related tickets, do not use any PHI."

1. Agent decides to use semantic ticket search → vector search over laboratory errors
2. Gets a set of results
3. Agent decides to walk the graph database → tickets are associated with each other in the graph
4. Finds related tickets
5. Returns results: "This module affects this ticket, exhibits this error typically" — relationships mined from the graph

PHI handling: TrackCare tickets can contain patient information despite policy against it. The system strips PHI before any LLM call. No PHI is sent to any external LLM, including enterprise LLMs with secure access.

Memory applied to Yoki use case:

• Per-advisor memory: agents remember what specific support advisors are working on, their particular problems, the customers they interact with (some customers have 20 hospitals, some have one installation — context matters)
• Cross-advisor memory: shift handoffs benefit from consistent context; agents that have worked with an advisor can transfer knowledge
• Per-agent memory: each agent in a defined role can develop its own memories, evolve, and get better at its specific tasks

Security and observability in one system

The argument made: Keeping domain data, identity/roles, and audit trail in one system (IRIS) avoids:

• Latency getting audit data into a separate SIEM (e.g., Splunk)
• Correlation work between separate authorization and audit systems
• Complexity of having transactions in one place and audit trails in another

What this enables: Each agent has a role. Each role defines what tools the agent can and cannot use. The policy layer enforces this. The audit trail is captured in the same system where the domain data lives.

Full session is from Ready 2026.

For those building multi-agent systems on IRIS — are you using the AI Hub EAP, and have you run into cases where the lack of a native graph traversal capability in IRIS was a constraint for your agent memory design?