Design multi-step AI processes — agents, tools, knowledge sources, and business systems — by wiring nodes on a drag-and-drop canvas, with governance and approval attached to every step rather than bolted on afterward.
One canvas orchestrating your entire process. Governed, observable, and always auditable.
Workflow canvas — retrieval, tool calls, routing, approval
The workflow builder lets you draft with MCP nodes, A2A nodes, and logic components, and assemble them into a workflow right on the canvas. Drag any of the 3 into place and connect them to build the process visually — no code required.
The workflow builder supports approval gates, conditionals, routers, loops, and parallel logic on the canvas — so a run can pause for human sign-off, branch on a state value, repeat until a condition clears, or fan a task out across several branches at once.
A node's dependency does not have to be 1 fixed server or agent. Add 2–5 candidates to a pool and the workflow reads the task's intent at run time to choose the best match — without fixed wiring or a separate registry lookup.
Every node execution emits an OpenTelemetry span, so a single workflow run produces a complete trace across MCP calls and agent handoffs. Duration, error rate, and throughput roll up per node and per workflow into your existing observability stack.
trace_id=7fa2c1 span=knowledge_lookup dur=312ms ok
trace_id=7fa2c1 span=router dur=4ms ok
trace_id=7fa2c1 span=a2a_handoff dur=891ms ok
p95 node latency: 480ms · error rate: 0.4% · runs/day: 1,204Each run streams node-by-node status with the input and output snapshot for every step visible as it happens. If a node fails, its retry policy takes over first, and an operator can retry only that node instead of restarting the workflow.
Explore Governed AI Layer{"event": "node_start", "node_id": "review", "attempt": 1}
{"event": "node_failed", "node_id": "review", "error": "timeout"}
{"event": "node_start", "node_id": "review", "attempt": 2}
{"event": "node_complete", "node_id": "review", "output": {"...": "..."}}
A workflow node never holds a model API key. It calls the LLM Gateway in Jarvis Registry, which selects the model suited to the agent's task and makes the call on the workflow's behalf. Credentials remain in the gateway.
Governed AI, Agent Registry, Agent Gateway, and orchestration in one enterprise platform.
AgentFlow is the workflow layer of the Jarvis AI platform: it turns intelligent AI agents into repeatable business processes with guardrails, retrieval, and actions attached. The 6 rows below summarise what a platform team needs to know before a first build.
| Aspect | What AgentFlow provides |
|---|---|
| What it builds | Multi-step AI agents that combine retrieval, tool calls, and actions rather than single-turn chatbot replies. |
| Starting point | Prebuilt starter agents that can be customised, or new agents assembled from scratch in the Jarvis Agent module. |
| Retrieval and actions | RAG over your own sources plus tool invocation, so an agent can look something up and then act on it in the same run. |
| Guardrails | Enterprise guardrails apply to every step, including PII redaction, denied topics, and full message logging. |
| Distribution | Finished agents are published to the agent marketplace so other teams adopt them instead of rebuilding them. |
| Where it runs | Inside your own Kubernetes cluster on 1 of 3 supported clouds — Amazon EKS, Azure AKS, or Google GKE. |
These are the protocol and runtime facts an architecture review asks for before approving agent workflows in production. Standards rows name the defining document, so a claim can be checked against its source rather than taken on trust.
| Specification | Value |
|---|---|
| Tool protocol | Model Context Protocol (MCP), published November 2024, transported over JSON-RPC 2.0 |
| Agent protocol | Agent-to-Agent (A2A) invocation with per-agent OAuth 2.0 client credentials |
| Authorization | OAuth 2.0 (RFC 6749) with Bearer token usage per RFC 6750 |
| Token format | JSON Web Token (RFC 7519), signed per JWS (RFC 7515) |
| Identity federation | OpenID Connect Core 1.0 and SAML 2.0 via Azure EntraID |
| Transport security | TLS 1.2 minimum (RFC 5246), TLS 1.3 preferred (RFC 8446) |
| Runtimes | 3 managed Kubernetes services — Amazon EKS, Azure AKS, Google GKE |
| Federated agent clouds | 2 — AWS AgentCore and Azure AI Foundry |
| Guardrail policies | 100+ prebuilt compliance policies across 4 control layers |
| Retrieval sources | 12 supported knowledge source types |
| Telemetry | OpenTelemetry OTLP spans for every workflow step |
| Denial responses | HTTP 401 for unauthenticated callers, HTTP 403 for policy denial |
| Zero-trust model | NIST SP 800-207 (published 2020), evaluated per request |
| AI governance model | NIST AI RMF 1.0 (released 2023) |
| Data residency | Prompt, response, and audit data stay in the customer account with private LLM deployment. If you connect an external model API, requests are sent to that provider. |
| Procurement | 2 marketplaces, 3 standard contract tiers, USD 18,000–60,000, plus private offers |
AgentFlow projects go wrong when they start from a demo rather than a bounded task. These 5 steps keep the first build narrow enough to measure and wide enough to be worth operating once it works.
Name the task, not the technology. Pick 1 repetitive process with a clear input and a checkable output — triaging a ticket, drafting a summary, answering a policy question.
Start from a starter agent. Clone a prebuilt Jarvis agent that already matches the shape of the task rather than assembling one from an empty canvas.
Attach retrieval. Point the agent at the knowledge sources it needs so its answers cite your own documents instead of general model knowledge.
Set guardrails before users. Enable PII redaction and denied topics, and decide which steps need human review before anything reaches production.
Publish and measure. Release to the agent marketplace, then use the audit trail to see how often the workflow runs and where it escalates.
The same graph of retrieval, routing, and approval nodes applies wherever a process combines multiple steps, multiple systems, and a judgment call in the middle.
A ticket arrives by email, a knowledge-lookup node checks internal documentation, and a confidence router either sends a grounded reply or opens a ticket for the support team to review.
A claim intake workflow pulls policy data, checks it against coverage rules, and routes anything outside policy to an adjuster instead of approving it automatically.
A request is checked against payer criteria, and any coverage gap escalates to a human reviewer through an approval gate before it reaches the provider.
These are the questions that come up in the first architecture conversation, answered at the level of detail an evaluation actually needs.
A chatbot answers a message. An AgentFlow agent runs a process: it retrieves context from your systems, calls tools, takes an action, and records what it did — all under the same policy and audit trail as the rest of the platform.
That difference matters operationally. Because each step is explicit, you can see which stage failed, replay it, and change one part of the workflow without rebuilding the whole thing.
No. Agents are assembled in the Jarvis Agent module from prebuilt workflow components, and the starter agents are designed to be customised rather than used as-is.
Teams that want deeper control still can: agents can call your own MCP tools, so anything you can expose as a tool becomes a step an agent is allowed to run.
Two layers. Guardrails filter content on the way in and out, covering PII redaction, denied topics, and word filtering. Access policy governs capability: an agent can only invoke the tools and agents its ACL entry lists.
Both layers are evaluated per invocation, so tightening a policy takes effect immediately rather than at the next deployment.
Published agents go to the agent marketplace inside your own deployment, which is what turns a one-team build into a shared internal asset.
Because the registry versions each agent, a team adopting someone else’s workflow binds to a specific version and is not exposed to changes made later by the original authors.
Every step of every run lands in the audit trail: the retrieval calls, the tools invoked, the policy version in force, and any escalation to a human reviewer. That is the raw material for judging whether agent workflows are earning their place.
Two numbers are usually enough to make the call in the first month. The first is run volume — how often the workflow is actually triggered rather than demonstrated. The second is escalation rate: the share of runs that a reviewer had to correct.
A workflow with high volume and a falling escalation rate is ready to widen. One with 0 real runs after a month is a demo, not a process, and is better replaced than tuned.
AgentFlow sits on top of the platform’s registry, retrieval, and governance layers. These pages cover each of them.
ASCENDING is an AWS Advanced Tier Services Partner with the AWS Generative AI Competency, and builds Jarvis as licensed software that runs inside your own cloud account. The specifications below define the protocols and controls AgentFlow builds on.
