Agent Overview

Every Oxagen agent — the in-app chat agent, the MCP server tools, and any external client calling the REST API — operates against a single capability surface. One tool definition, three call sites, the same workspace, the same audit log.

One agent, three call sites

Every call is workspace-scoped, credit-metered, and audited. Tools read and write the same Neo4j-backed graph regardless of surface, so an edit a developer makes from Claude Code shows up in the dashboard chat on the next turn and is visible to a Celery worker hitting the REST API a second later.

Capability families

The catalog at Agent Tools is the canonical contract. If a tool isn't in the catalog, it isn't exposed.

Read

• Ontology — read. Hybrid search, typed fetches, list-by-type, schema introspection, read-only Cypher, merge-candidate detection, and outward graph traversal. The agent's most-used family. See Ontology — read.
• Code graph. Symbol lookup, callers / callees, dependency graphs and shortest paths, blame and PR context, change history. Available once a GitHub connection has ingested code. See Code graph.
• CI / test layer. Last CI run status, failing steps, tests covering a target symbol, coverage, flaky-test detection, dead code, and cycle detection. Scoped to the connected GitHub workspace. See CI / test layer.
• Security. Open alerts and alert context from GitHub code scanning, Dependabot, or Semgrep when connected. See Security.
• Graph algorithms. PageRank, communities (Louvain / label propagation), and bounded path enumeration on Neo4j-routed workspaces. See Graph algorithms.
• Memory. Durable agent memory: patterns the agent has learned, procedures it has been taught, recent work it should remember. See Memory and the deeper model in Agent Memory.
• Web. A narrow outbound surface — public web search and URL fetch — so the agent can pull in external context without leaving the registry. See Web.

Write

• Ontology — write. Typed creates and updates against the graph, alias registration, type attachment, and destructive operations (delete, merge, rename) that always prompt for confirmation in the chat UI. See Ontology — write.
• Code — write. A single primitive — code.apply_patch — that opens a draft pull request carrying a unified diff. Nothing merges automatically. See Code — write.
• Workspace + tenant. Label management, tenant settings, workspace credit balance. See Workspace + tenant.

Generate

• Documents. Google Docs from a typed DocumentSpec — headings, paragraphs, lists, tables, images. See Document generation.
• Spreadsheets. Google Sheets from a SheetSpec — typed columns, formatting, charts. See Spreadsheets.
• Slides. Google Slides decks from a SlideDeckSpec — layouts, speaker notes, placeholders. See Slides.
• PDF. Render any generated artifact (or any office-format upload) to PDF through the generic LibreOffice converter. See PDF generation.
• Branding. Every artifact picks up the workspace's active BrandKit — palette, typography, spacing, logo, favicon, voice doc, footer. See Brand kits.
• Artifact storage. Every artifact lands in app.documents with source='agent_generated' and a back-reference to the agent run that produced it. See Artifact storage.

Coordinate

• Agent sessions. Coordination primitives for swarms — named sessions, exclusive work claims on a node and its neighborhood, and typed findings the next agent can pick up. See Agent sessions.
• Events and triggers. Ontology events (node.created, edge.created, source.completed, …) on the Redis-Streams bus feed user-defined WorkspaceAgentTrigger rows that enqueue prompted agent runs. Every run leaves an entry in audit.event and run.step chains that roll up into the daily Merkle attestation. See Events, triggers, and audits.

Notify and visualize

• Notify. A single notify.dispatch primitive that pushes structured notifications to a pre-configured webhook, Slack, or email channel. See Notify.
• Visualization (app surface only). The chat agent renders interactive graphs, tables, and charts inline in assistant messages. MCP and API surfaces skip these — your IDE renders its own UI. See Visualization.

Same tools, same workspace, same audit log

Calling a tool from any of the three surfaces hits the exact same handler and the exact same database. There are no surface-specific side branches. Concretely:

• A code.apply_patch invoked from Claude Code and one invoked from the dashboard chat both go through the same draft-PR opener and show up in the same audit log under the same workspace.
• A memory.remember call from a Celery job using the REST API surfaces immediately when an in-app chat resumes the conversation.
• Credits are reserved against the workspace before the handler runs and refunded if the handler errors — the cost shown in the catalog is what a successful call deducts, regardless of which surface made it.

Where to go next

• Agent Tools — the canonical capability catalog with credit costs and surfaces.
• Agent Memory — the deeper model behind the memory.* tools.
• Artifacts — what the agent produces and where it lands.
• Events, triggers, and audits — how ontology events fire prompted agent runs and how every run is attested.
• Web App Walkthrough — the chat surface, prompt box, graph viewer, and confirmation cards.
• MCP Server — install commands for each supported client and the MCP surface's auth and rate limits.
• API Reference — every public REST endpoint plus the capability surface (/v1/cap/<name>) that exposes every tool.

---

Get started free · Install MCP server · Read the API docs