> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dabarai.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Autonomous Agents

> Turn a DABAR project into an autonomous agent your team debates with in real time, connected to your systems via MCP — under the same Policy Engine governance as the research layer.

Research is the beginning, not the end. Every Project in DABAR can become an **Autonomous Agent** — a service that answers questions, executes workflows, and connects to your existing systems under the same policy governance as the research layer.

## From Project to Agent

The lifecycle is simple:

1. You build a **Politic** — the rules of reasoning.
2. You run a **Project** — apply the politic to a body of sources.
3. You **deploy** the project as an Agent — exposing it to users, systems, or other agents.

The agent doesn't forget the rules. Every action it takes, every answer it gives, is still labeled `CONFIRMED`, `NOT FOUND`, or `ESTIMATED` and still cites its sources.

## What agents can do

Agents go beyond Q\&A. A DABAR agent can:

* **Answer** grounded questions from your team or customers.
* **Analyze** new inputs on demand — an incoming contract, a new application, a fresh data feed.
* **Act** in external systems — open a ticket, update a record, send a notification, trigger a workflow.
* **Collaborate** — hand off to other agents or escalate to a human when a rule demands it.

## Connectivity

Agents connect outward through several transport layers:

<CardGroup cols={2}>
  <Card title="MCP" icon="plug">
    Model Context Protocol — the standard way DABAR agents expose tools and consume tools from other systems.
  </Card>

  <Card title="REST APIs" icon="code">
    Call any HTTP service your organization exposes, inside the VPC or over the public internet.
  </Card>

  <Card title="Custom skills" icon="wrench">
    Package organization-specific logic as a reusable skill an agent can invoke.
  </Card>

  <Card title="Browser automation" icon="window">
    Drive web interfaces that don't expose APIs — scoped to the sites you allow.
  </Card>
</CardGroup>

## Governance still applies

An agent is not a loophole around the Policy Engine. Every action an agent takes:

* Is constrained by the politic it was deployed under.
* Is logged with inputs, outputs, sources, and labels.
* Can be suspended or rolled back by rotating the underlying politic.

This is why DABAR agents are safe to put in front of regulated workflows — the enforcement surface is the same whether the agent is answering a question or writing to a database.

## Example: the credit committee

A bank deploys a **Credit Risk Agent** built from a politic that encodes its lending guidelines, grounded on the loan applications in the current batch.

The committee queries it live:

> *"What's the environmental risk profile for applicant 0142?"*

The agent answers with labeled, cited findings. If the committee asks it to escalate, the agent opens a ticket in the bank's internal system — still under the same politic, still with a full audit trail.

The same agent, same politic, same sources — now driving a decision in real time.

## Next

<CardGroup cols={2}>
  <Card title="Deploy a project" icon="rocket" href="/api-reference/projects/deploy">
    Promote a draft project into a live agent.
  </Card>

  <Card title="Policy Engine" icon="scale-balanced" href="/concepts/policy-engine">
    The rules every agent inherits from its politic.
  </Card>
</CardGroup>