Agents, workflows, and MCP integration

Agents and workflows

• Agents. Create, version, share, import, export, and run agents. Each agent has an owner, a tool allow-list, and limits on tool iterations per run. An agent can be held to its listed tools and required to use a tool before it answers.
• Multi-agent workflows. Chain agents and tools with condition, branch, loop, and transform steps. Workflows can be created by describing the process in plain language, then edited.
• Detached runs. A run continues after the request that started it, with step-level progress in a live workspace. Operators can stop, hold, steer, or resume a run. Steering lands at the end of the current step. Interrupted runs resume only when repeating their work is safe, so tools must be marked read-only or idempotent.
• Scheduling. Cron expressions, intervals, and one-time schedules with time zones. A distributed lock prevents double runs in a cluster. Scheduling requires Redis.
• Monitoring and alerting. Run counts, success rates, alert rules, and notification channels for email and webhooks (including Slack and Teams).
• Test suites. Save test cases per agent, with expected outputs, expected tool use, and assertions, and run them as regression tests.

Solution blueprints

Four ready-made blueprints: document intake and triage, RFI response, research brief, and compliance evidence check. Blueprints carry the definition of a solution, never its data or credentials.

Findings pages

A page can run a solution on a chosen document and show what each agent found.

Findings are the agents' answers and are not checked against the document.

Tools

Agents use reusable tools:

• REST, GraphQL, and webhook tools
• Database tools for PostgreSQL, CockroachDB, MySQL, SQL Server, Snowflake, Databricks, MongoDB, Elasticsearch/OpenSearch, and Salesforce
• Custom-function tools written in JavaScript
• Tools from external MCP servers, through the MCP client

Administrators can search the tool picker, and governed tools are listed first. Every tool call is subject to policy and approvals.

Sandboxed custom tools

Custom-function tools always run in an isolated V8 sandbox with a five-second wall-clock limit, a 128 MB memory limit, and no filesystem or process access. Network access is available only when a tool declares it, and requests to loopback, private, and link-local addresses are refused.

Wall clock

5 seconds

Memory

128 MB

Filesystem / process

No access

Network

Declared only; loopback, private, and link-local refused

MCP gateway for external agents

The MCP gateway lets an MCP-capable agent, such as one running in an IDE or another agent framework, ask ARIA for a governance decision before it acts. Available tools include policy evaluation, action governance, status polling, execution confirmation, evidence export, and tool listing and execution.

The gateway is off until an administrator enables it, and it uses ARIA API keys with separate permissions for invoking the gateway and executing tools. Gateway calls appear in the run trace and the audit log (see Trust layer and audit). Output returned to external agents is screened for prompt injection, and a caller that has read suspicious content has its risky actions held. See Prompt-injection defense.

For what ARIA governs for external agents, and what it does not, see Scope and boundaries.

Budgets and usage

Token and cost usage is recorded per user, role, and organization. Budgets can be set by provider, model, agent, workflow, group, user, role, or organization, with alert thresholds and a default hard-stop action.

Frequently asked questions