Build a compiled agent fleet that stays in their lane
A domain-extensible agent builder for analytics and operational automation. Your team describes a workflow in plain English; the platform compiles it into many small, scoped agents that run where your data lives, in sequence or in parallel.
What to expect once it is running
Measured on a 5-step TPC-DS analytics workflow, compiled against the same spec on an interpreted runtime.
Workflows are data, so your domain team owns them
Most agent platforms give you a chatbot that picks its tools at runtime. That works for generic tasks. It is the wrong shape for encoding proprietary know-how, like a 14-step quality-deviation investigation or a supplier-SLA breach playbook, where you need predictability, auditability, and reuse.
In AgentFlow, a workflow is a declarative spec: the steps, the tools each step may use, the gates that must pass, and where to branch. Each step compiles into its own small scoped agent, so a workflow is deterministic orchestration of many small agents. Steps that work on a list fan out into one agent per item, all running at once, and fold their results back into a single output before the graph moves on.
The spec is a versioned JSON document in your own object storage, not code in an engineering repository. Process engineers, quality leads, and analysts author and change workflows without an engineering ticket, and the workflows stay assets you own.
A loop wanders. A graph runs the order you defined.
Same tools, same data. One lets the agent decide everything at runtime. The other compiles your intent into a fixed graph of scoped steps.
Picks its own tools and its next move every turn. Nothing stops a wrong turn.
A fixed order of scoped steps. The wrong step is not reachable.
Your data, your storage, your choice of model
The runtime sits between the people and systems that trigger work and the storage that holds both your data and your workflows. The model layer is called from the runtime only.
ANALYTICS RUNTIME
The graph runs in order, and every step is checked before the next one starts
Each step compiles into its own scoped agent. An assertion must pass before a step advances. Where a step works on a list, it fans out into one agent per item and folds the results back.
One run-token, one defined path. Each node sees only its own tools.
Fails the check, retries with the validator’s complaint, advances only when it passes.
Plain loop, no gate: a wrong result just moves on.
One agent per item, all in flight at once, folded back into a single result. You cap how many run at a time.
The agent asks for measures, not for tables
Point a project at your semantic layer and the raw-SQL and catalog-browsing tools leave the toolset. What the model can ask for is what the layer defines, and the layer writes the SQL.
The definition of revenue lives in whoever wrote the query. Two workflows can answer the same question two ways and both look right.
One definition of revenue, shared by every workflow. Raw SQL is not in the toolset, and a blocked tool reached another way is refused.
Nine constructs you will actually use
Each one is a building block your domain team can combine without writing application code.
01 Boundaries in the architecture, not the prompt +−
A goal-driven agent is told what not to do in its system prompt, and can drift past it. Here the compiler controls the graph: the wrong tool is not in the step’s toolset and the wrong step is not reachable.
02 Eight step types, with gates +−
An agent step reasons openly toward a goal. A guided step must call a named tool to advance. A conditional step branches on a value from an earlier step. A map step fans out over a list. A transform step runs SQL with no model call at all. A wait-for-input step pauses for a person, an action step changes something in the world, and a subworkflow step calls another workflow you already published. Any step can carry gate checks, assertions, and retry with the validator’s complaint as context.
03 Parallel by construction, with fan-out at the step level +−
A map step takes a list produced earlier in the run, starts one scoped agent per item, and folds every result back into a single output through a reduce before the graph moves on. You set how many item agents run at once, from 1 to 256, and each one can carry its own pinned model. Triggers fan out the same way at the workflow level, firing as many as 10 workflows in parallel from one event.
04 Per-step scoped agents keep runs cheap +−
Each step sees only its own tools and instruction, so context stays small and prompt caching applies per step. On a 5-step TPC-DS workflow that is 94.7% fewer total tokens than the same spec on an interpreted single-agent runtime.
05 A model chosen per step +−
Every step that calls a model can name the one it runs on, picked from the model registry your admin curates. Heavy reasoning sits on a frontier model while bulk extraction runs on a cheaper one, and a step that touches sensitive data can be pinned to a self-hosted model. Steps with no pin inherit the run’s model. A pin naming a model nobody registered fails the build rather than quietly running on something else.
06 Triggers as a single record +−
One persisted trigger holds the cron expression or webhook URL, fan-out to as many as 10 workflows, per-workflow input mapping, retry policy, and its own last-fired audit. Authored once, reused everywhere.
07 Action steps that can be approved +−
For steps that change something in the world, the lifecycle is fixed: plan, freeze the plan with a fingerprint of its inputs, route for approval with timeouts and escalation, execute only on approval, then write an append-only audit record.
08 Skills, subagents, MCP servers, and your own tools +−
A skill is a packaged playbook for a class of problem. A subagent handles a delegated sub-task with its own reasoning loop. A custom tool is your Python function, registered once and callable from any step in any workflow. An MCP server you already run plugs in as a connection: its tools show up to the agent like any other tool, in chat and in compiled workflow steps alike, and you can pare a chatty server down to the few tools you want. The token travels in the outbound request to your server and never enters the model’s context.
09 Memory, observability, and audit +−
Run state is checkpointed so a run survives a restart or waits days for a human. Project memory holds facts across runs, catalog memory holds descriptions and embeddings of your data, and every run emits a structured event stream with per-step token usage.
The clouds give you parts. This is the product.
AWS and GCP ship strong primitives for model hosting, code execution, scheduling, and identity. What neither ships as one product is the agent-builder layer above them.
94.7% fewer tokens on the same five-step workflow
A 5-step TPC-DS analytics workflow, run two ways. Compiled into per-step scoped agents with per-step prompt caching, against the same spec on an interpreted runtime that gives one agent every step and every tool. Same workflow, same data, same output.
See the engine underneath →Priced on the platform, not per seat
AgentFlow is licensed for the deployment you run, with model spend billed by whichever provider you route to. Because runs compile into per-step scoped agents with prompt caching, the token side of the bill stays far below an interpreted equivalent.
Book a demo for pricing. Talk to us and we will scope it against the workflows you want to author first.
It works with the models, systems, and stores you already chose
AgentFlow questions
Plain answers for the evaluator in the room.
How is this different from an agent that just picks its own tools?+−
A goal-driven agent is bounded by its system prompt, which it can drift past. Here the compiler owns the graph, so the wrong tool is not in a step’s toolset and the wrong step is not reachable. For regulated and audited work, that difference is the whole point.
How do you stop it from querying the wrong thing?+−
Point the project at your semantic layer and the raw-SQL and catalog-browsing tools are removed from the agent’s toolset. It can ask only for the measures and dimensions the layer defines, and the layer resolves the joins and generates the SQL. Your existing metric definitions bound the agent, so you do not have to read generated SQL to trust the number.
Can steps run in parallel?+−
Yes. A map step turns a list into one scoped agent per item, runs them at once, and reduces the results into a single output before the next step starts. You cap how many run at a time, and each item agent can carry its own model. One trigger can also fire as many as 10 workflows in parallel from a single event.
Where does my intellectual property live?+−
Workflow specs, the skill library, custom tools, project memory, run history, and the audit log are versioned in your own object storage. They are not held in vendor systems.
Can it act on operational systems without a person watching?+−
An action step plans, freezes the plan with a fingerprint of its inputs, routes it for approval with timeouts and escalation, executes only on approval, then writes an append-only audit record. Nothing irreversible happens without a trail you can inspect.
Am I locked into one model vendor?+−
No. You can route to Bedrock, Anthropic, OpenAI, Gemini, Azure OpenAI, or a self-hosted open-weights model, and you can choose per step. Heavy reasoning can sit on a frontier model while routine extraction runs on a cheaper one.
Can it use the tools we already expose over MCP?+−
Yes. An MCP server is added as a project connection over HTTP or SSE, with a token or OAuth, and its tools become available to the agent in chat and inside compiled workflow steps. You can pare a chatty server down to the tools you want, and bound which hosts the runtime may reach. A server that is slow or down means no MCP tools that turn, never a failed run.
Why is it cheaper to run than a single-agent setup?+−
Each step is compiled into its own scoped agent with only its tools and instruction, so context stays small and prompt caching applies per step. On a 5-step TPC-DS workflow that measured 94.7% fewer total tokens.
Where can it be deployed?+−
SaaS, in your own cloud account, entirely inside your VPC with no vendor egress, or on-prem and private cloud. Non-hyperscaler and sovereign clouds are supported with the same architecture.
What was MetrIQ?+−
MetrIQ is the former name for this product. The constructs, deployment models, and runtime are the same.
Book a demo on your own workloads
Reach out to book a demo, share challenges you're facing, and tell us how this fits into what you're currently working on or thinking about.
Prefer to self-serve? Problems we're solving →