Integrations

Iranti fits under your existing workflow.
It does not ask you to rebuild your stack around it.

The right integration story for Iranti is simple: keep your agents, your orchestration, and your model choices. Add a memory layer that survives sessions, survives agent boundaries, and gives operators something inspectable when a workflow goes sideways.

Native paths
Claude CodeNative
iranti claude-setup

Deepest current integration: MCP plus hooks, including pre-turn retrieval and post-response persistence on the Claude path.

  • •Writes .mcp.json, .vscode/mcp.json, and .claude/settings.local.json
  • •SessionStart, UserPromptSubmit, and Stop hooks
  • •Best fit when you want memory retrieval without relying on model discretion
CodexNative
iranti codex-setup

MCP-native integration for Codex CLI and VS Code. The current setup path covers global Codex config and workspace MCP scaffolding.

  • •Global Codex registration plus workspace MCP files
  • •Best fit for exact recall, shared facts, and explicit durable writes
  • •Useful paired with project binding and doctor checks
iranti chatNative
iranti chat

Operator-facing inspection surface for debugging memory, seeding facts, checking history, and understanding what the system currently believes.

  • •Good for handoff debugging and conflict inspection
  • •Lets you query, inspect history, and verify confidence/provenance directly
  • •Complements the UI rather than replacing the API or SDK
SDK and API paths

The bigger opportunity is not one IDE.

Iranti matters most when the memory layer can outlive any one tool. That is why the site keeps pointing back to SDKs, HTTP integrations, and cross-tool handoffs instead of sounding like the product only exists inside Claude Code or Codex.

Raw HTTP / OpenAI-style stacksValidated

Strongest for teams building their own orchestration and wanting the fewest assumptions.

LangChainValidated

Best framed as a framework you plug into Iranti, not as a memory system Iranti competes with directly.

CrewAIValidated

Best demonstration of shared-memory handoff: one role writes, another role retrieves, neither relies on shared prompt state.

Custom agent systemsGeneral

If your agents can make HTTP or SDK calls, Iranti can usually sit underneath them as the memory layer.

What integration success looks like

Agent A writes a fact. Agent B can retrieve it cold later, in another process, without borrowing A's prompt context.

An operator can inspect the state. They can query the fact, inspect provenance, review conflicts, and reason about what happened.

A tool swap does not destroy memory. Claude, Codex, HTTP clients, and SDK consumers all point at the same underlying system of record.

Boundaries
Iranti is strongest when the client can make explicit read and write calls, or when the host supports deterministic hooks.
Browser-tab AI memory injection is not the product. CSP and host limits make that the wrong abstraction layer.
Framework integrations should be described as framework-agnostic persistence, not as deep framework orchestration.

Ready to choose a path?

Closed beta is running now — reach out to request early access, or read the evidence page first if you want the proof before anything else.

Read the evidenceRequest access