Question 1

Why use Tokonoma instead of built-in memory, a generic MCP, or runbooks?

Accepted Answer

Built-in memory is agent-specific and geared toward generic facts, not specialized expertise. A generic MCP only exposes tools or data, and runbooks require manual upkeep. Tokonoma captures resolved production investigations, ties them to services and symptoms, and keeps that knowledge current as new evidence appears.

Question 2

Which agents and tools does Tokonoma support?

Accepted Answer

Tokonoma supports Claude Code, Cursor, and Codex through MCP. It works alongside existing agent connections to source code, CI/CD, tickets, chat, incident management, and observability tools including Datadog, Grafana, and Sentry.

Question 3

Where does Tokonoma deploy, and what access does it need?

Accepted Answer

Tokonoma runs in your cloud account or Kubernetes environment, so the platform and investigation records stay inside your boundary. It uses permissions already granted to your coding agent instead of requiring separate standing access to production.

Question 4

How can engineers verify Tokonoma's guidance?

Accepted Answer

Every recalled investigation includes attribution, root cause, ruled-out paths, the fix, and supporting references. Recall cards show why guidance surfaced; session receipts show which expertise the agent used.

Question 5

What if our telemetry is incomplete, noisy, or expensive?

Accepted Answer

Keep the observability tools that work for you. Tokonoma's included telemetry can fill instrumentation gaps or take on signals that are too noisy or expensive in your current stack.

Question 6

How do teams get started?

Accepted Answer

Start with one service, the coding agents your team already uses, and a small set of trusted investigation sessions, skills, and runbooks. Each resolved investigation then improves what future responders can recall.

FAQ