Intelligent AI Agent Workflows
Jarvis AgentFlow at a glance
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. |
AgentFlow technical specifications
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 | 0 bytes of prompt, response, or audit data leave the customer account |
| Procurement | 2 marketplaces, 3 standard contract tiers, USD 18,000–60,000, plus private offers |
How to build your first agent workflow
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.
Where the guardrails sit
AgentFlow inherits the platform governance layer, so policy and human review apply to every step of a workflow rather than only to the final response.
AgentFlow questions we are asked most
These are the questions that come up in the first architecture conversation, answered at the level of detail an evaluation actually needs.
How is AgentFlow different from a chatbot?
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.
Do we need to write code to build an agent?
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.
What stops an agent from doing something it should not?
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.
Where do finished agents live?
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.
How do we know an agent workflow is actually working?
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.
Related Jarvis capabilities
AgentFlow sits on top of the platform’s registry, retrieval, and governance layers. These pages cover each of them.
- Agent Registry — the catalog, versioning, and lifecycle layer beneath published agents.
- Jarvis Knowledge Base — the governed retrieval tool AgentFlow agents call for context.
- Jarvis AI Guardrails — PII redaction, denied topics, and human-in-the-loop escalation.
- MCP Gateway — how agents reach enterprise tools through one governed endpoint.
- Jarvis AI platform FAQ — licensing, hosting, and compliance questions across the platform.
Standards and references
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.
- Model Context Protocol (MCP) — the tool-access standard agent steps use to reach enterprise systems.
- NIST AI Risk Management Framework — the governance reference behind guardrails and human review.
- Kubernetes documentation — the runtime AgentFlow deploys onto in every supported cloud.
- Jarvis on AWS Marketplace — procurement path for private offers and standard contracts.
