Agent Governance and Control
Agents in Haystack Enterprise Platform loop: the model chooses tools, runs them, and continues until an exit condition is met. Governance means defining how long an agent can act, which tools it can call, who can deploy or invoke it, and how you observe each run.
Execution Limits
Maximum Agent Steps
The Agent component accepts max_agent_steps, a cap on how many actions (tool calls and model turns) one run can take. Lower values reduce runaway loops and cost; higher values support multi-step research tasks.
Configure this in Builder under the Agent Advanced tab or in YAML. See Configure Agent's Advanced Settings.
Exit Conditions
exit_conditions define when the agent stops. Common patterns:
- Stop when the model returns a text reply (no further tool use).
- Stop after a named tool runs (for example, after a final "submit" tool).
You can combine conditions; the agent stops when any of them is met.
Tool Failures
retry_on_tool_failure controls whether the agent retries after a failed tool call. Use it for transient errors; turn it off when repeated retries would amplify cost or side effects.
Tool Surface Area
Agents can use:
- Pipeline tools (other deployed pipelines exposed as tools)
- Python tools (custom functions you define)
- MCP tools from servers you configure in the workspace
Each tool expands what the agent can reach on your network or in your data. Restrict tools to the minimum needed for the task. For MCP wiring and security considerations, see Agent Tools and Model Context Protocol.
Access Control
Who can change agents and who can run them is governed by RBAC:
- Deploying or editing pipelines requires workspace permissions on pipelines and related assets.
- Running queries in Playground or through the API requires appropriate workspace roles (for example, Search User or Editor).
See User Roles and Permissions.
Observability and Review
Every deployed pipeline run can produce a trace with spans per component, tool inputs and outputs (where recorded), token usage, and failure stack traces. Use traces to review agent decisions after the fact.
See Trace Your Pipelines in the UI.
Governance Requirements and Platform Features
AI regulations, such as the EU AI Act, and internal AI policies often ask for the same kinds of controls: traceability, record keeping, human oversight, and restricted access. This table maps these common requirements to the platform features you can use to meet them:
| Requirement | Platform features |
|---|---|
| Traceability of agent decisions | Traces with a span for each component and tool call, including inputs, outputs, token usage, and errors. See Trace Your Pipelines in the UI. |
| Record keeping and audit trail | Search history, pipeline traces, and pipeline logs. See What's the Retention Policy for Search History and Pipeline Logs?. |
| Change management | Pipeline versions you can compare, restore, and deploy. See Manage Pipeline Versions. |
| Restricted access | Role-based access control (RBAC) with preset and custom roles at the organization and workspace levels. See User Roles and Permissions. |
| Limited autonomy | Step limits, exit conditions, and an explicit list of tools for each agent. See Execution Limits and Tool Surface Area. |
| Human review of outputs | User feedback collected on pipeline answers, and offline evaluation with jobs. See Collect User Feedback and Jobs. |
| Control over where data is processed | Managed cloud, self-hosted, and air-gapped deployments, and a choice of model providers. See Deployment Options. |
These features support your governance process, but they don't make a system compliant on their own. Whether a system meets a regulation depends on its use case, risk classification, and your organization's processes.
What the Platform Does Not Provide
These items often appear on enterprise checklists but are not built-in product controls today:
- A global kill switch that stops a single long-running agent mid-flight from the UI
- Per-user human-in-the-loop approval gates before every tool call
- Automated prompt injection or red-team testing in the Builder
You can partially mitigate risk with step limits, narrow tool lists, VPC boundaries, external observability, and offline evaluation with Jobs.
Related Information
Was this page helpful?