Agents you can trace, budget and interrupt.
One agent node, 6 model vendors plus local models, tools built from anything in the catalog, and a trace that shows every iteration with its tokens, latency and cost. Budgets and human approvals sit in the engine, so an agent can never spend or act beyond what you allowed.
Provider-neutral tool calling with a full trace.
The agent node takes a goal, a model and a list of tools. It loops through think → call → observe until it is done or a limit is hit, and every iteration is written to the run’s trace.
- builtin
- Think, calculate, current time, structured recall.
- HTTP
- Any REST endpoint, with a saved connection for auth.
- node
- Any of the catalog’s node types, exposed as a callable tool.
- code
- A Python function the agent can invoke with arguments.
- workflow
- A published workflow. The agent sees its input schema as the tool signature.
- MCP
- A remote Model Context Protocol server and every tool it lists.
Memory
Per-run by default, or a Redis-backed window that survives across runs for the same conversation key.
JSON-schema output
Declare the shape you want and the node returns validated JSON, so the next step gets typed fields instead of prose.
- 1builtin.thinkplan: look up the order, check the refund policy1,204 tok · 812 ms · $0.0041
- 2workflow.lookup_orderorder #48213 · delivered 2 days ago388 tok · 1,290 ms · $0.0013
- 3mcp.policy_searchrefund window 14 days · eligible961 tok · 640 ms · $0.0032
- 4human.promptrefund > $200 → waiting for approval142 tok · 0 ms · $0.0005
Six vendors, two cloud connectors, and your own hardware.
Pick a model per node or set a default for the workspace. Local models run on a dedicated worker pool so a slow inference never blocks the rest of the queue.
- Anthropic· vendor
- OpenAI· vendor
- Google· vendor
- Mistral· vendor
- DeepSeek· vendor
- Perplexity· vendor
- Azure OpenAI· connector
- AWS Bedrock· connector
- vLLM· local
- Ollama· local
Model catalog
Models are discovered from each connected provider and kept in a catalog with their context size and pricing. New models appear when the vendor ships them.
Default-model picker
Set the default model per workspace once. New agent, classify and extract nodes inherit it; any node can override.
Local models via vLLM and Ollama
Point the local worker pool at a vLLM or Ollama endpoint and the same agent node runs against it. Nothing leaves your network.
An agent can only spend what you gave it.
AI spend is tracked per tenant and per provider in tokens and in USD. Budgets are enforced by the router on every model call, not reconciled from an invoice a month later.
Monthly token and USD budgets
Per tenant and per provider. The dashboard shows spend against budget and which workflows are responsible.
Circuit breaker per provider
When a budget is spent or a provider starts failing, the breaker opens. Runs that would call it are held with a clear reason instead of retrying blindly.
Response cache
Identical prompts to the same model are served from cache within a window you set, which cuts cost on classify and extract nodes that see repeated input.
ai.guard safety node
ai.guard checks a prompt or a response against rules you define (PII, off-topic, prompt injection patterns) and routes the run when a rule trips.
Human approvals
Put a human.prompt node after the agent, or give the agent one as a tool. A person decides before a refund, a deletion or a message goes out.
Trace and ledger
Every model call is a ledger entry: workflow, run, node, model, tokens, USD. The trace viewer and the ledger agree because they are the same data.
Retrieval as three nodes and a vector store.
Load documents, chunk them, embed them, and write to the vector store you already run. Query the same store from an agent tool or a dedicated search node.
- ai.load→
- ai.chunk→
- ai.embed
- →
- Qdrant · Weaviate · Pinecone
Loaders cover files, URLs and the data nodes in the catalog. Chunking is size- or structure-based. Embeddings use any vendor in the model catalog, including local ones.
Model Context Protocol in both directions.
Your workflows become tools for the coding agents your team already uses, and your agents can call any MCP server you point them at.
Every published workflow is a tool.
The workspace exposes a Streamable HTTP MCP endpoint. Connect Claude Code, Cursor or any MCP client and it lists your published workflows with their input schemas. The client calls the tool; OCNORA runs the workflow under the caller’s API key, with the same budgets, permissions and audit log.
Agents call external MCP servers.
Add an MCP server as a tool of kind mcp and the agent sees every tool it publishes. Calls appear in the trace like any other tool call, with tokens, latency and cost.
Describe the workflow. Get a graph that passes validation.
Type what you want in plain language. The builder plans the workflow, maps each requirement to real node types, generates the graph, and repairs it until the validator is satisfied.
- 1. plan
- 2. node plan
- 3. coverage matrix
- 4. generate
- 5. validate
- 6. repair
- 7. lint
- 8. layout
Coverage matrix
Each requirement in your description is mapped to the node that satisfies it. Anything unmapped is reported, not silently dropped.
Validation report
The result is marked VALID, INVALID or NEEDS_CLARIFICATION. The last one comes with the question the builder needs you to answer.
Fix and explain
Two more endpoints: fix takes a failing workflow and returns a repaired one; explain turns a graph into a paragraph a colleague can read.
Stand-ins for missing apps
If your description names an app that is not in the catalog yet, the builder inserts a stand-in node and files an app request so the team can see the demand.
Same validator as Workflow Health
Generated workflows go through the same static validation, pre-flight and dry run as hand-built ones. The builder never publishes something Health would reject.
Lint and layout
Generated graphs are linted for dead branches and unused outputs, then laid out on the canvas so you can read them left to right.
Judge and metrics runner, via the API.
Run a workflow or an agent against a dataset, score each output with a judge model or a metric, and compare runs. Evaluations are available through the API and the builder’s evaluation panel; there is no separate evaluations dashboard yet.
{
"workflow_id": "wf_support_agent",
"dataset_id": "ds_tickets_2026_08",
"judge": { "model": "claude-sonnet", "rubric": "helpful, accurate, no refund without approval" },
"metrics": ["exact_match", "latency_ms", "usd"]
}Put an agent in a workflow this afternoon.
Start from the support-agent template, set a budget, add a human gate, and read the trace of the first run.