Skip to main content
For the complete documentation index for agents and LLMs, see llms.txt.

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.

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.