Take your first step toward AI governance with our Browser Extension. Start free trial →

Book a demo →

AG Agents

Operations · Agent builder

Give it a job.
Keep the receipts.

An agent in Governance 1st is a system prompt, a model, and a tool belt you choose deliberately. It reasons, calls a tool, reads the result, and goes again until the work is done or it hits something it is not allowed to do on its own. Every one of those steps is written down.

Book a demo → Back to Operations →

The loop

Reason, act,
observe, repeat.

The engine runs a reason-and-act loop. It loads the agent's configuration and tools, builds a prompt from the conversation so far plus the tools available, calls the model, parses out any tool call, executes it, feeds the result back, and goes around again. The loop is bounded, so a confused agent stops rather than spinning.

You write the brief

Name, description, system prompt, model and provider, temperature, and token ceiling. Nothing is inferred for you. The agent's instructions are a document you own and can revise.

You pick the tools

Tools are assigned per agent, not granted by default. An agent that should only read documents gets exactly that. Nothing in the prompt can talk it into more.

Three execution modes

Chat for a person driving each turn, assisted for work that runs but checks in, autonomous for tasks that run to completion on their own. The mode is a property of the agent, not a runtime accident.

Bounded reasoning

The loop has a hard step ceiling. An agent that cannot finish inside it stops and reports where it got to, instead of burning tokens in a circle.

Safeguards travel with it

Guardrails, content filters, and reference documents attach to the agent the same way they attach to a chat. The boundaries you wrote once apply everywhere they are used.

Persistent memory

Agents can commit facts to memory and recall them on later runs, so a weekly job remembers what it saw last week. Memory can be inspected and wiped.

The tool belt

Real actions,
not just text.

An agent that can only produce prose is a slower way to write. These agents touch the systems the work actually lives in: the record, the document, the calendar, the committee mailbox, the risk register.

search_web query_database create_record update_record read_document create_document send_email notify_committee schedule_meeting create_action_item search_risks link_risk_to_usecase log_incident get_employee_data wait_for_approval call_agent remember recall write_app_data

Where the leash is

Risk is a property
of the tool, not
a promise in
the prompt.

Reading a document and sending an email are not the same act, and the platform does not treat them the same. Each tool carries a risk level and an approval flag. When an agent reaches for something gated, the run pauses, an approval request is filed against a named role, and the agent waits. Not a warning in a log somewhere. A stop.

Risk-tiered tools

Every tool has a risk level. Approval requirements are configured on the tool, so they cannot be prompted away.

Blocking approvals

A gated action files a pending approval assigned to a role and holds the run there until a human decides.

Committee notification

Agents can notify the committee that owns an area directly, so oversight is a step in the work rather than a report after it.

Incident logging

An agent that encounters something wrong can file an incident against the register instead of failing quietly.

Full step trace

Each reasoning step, tool call, parameter set, and result is recorded against the task. Runs are reconstructable after the fact.

Rate limits

Deployed agents carry a per-hour request ceiling, so an integration bug cannot turn into a bill.

Agents calling agents

One agent can
hire another.

Any agent can be exposed to another agent as a callable tool. A coordinator delegates a self-contained task to a specialist, waits for it, and reads the output. Sub-agent tasks can run in the background, so a parent can dispatch several and collect results as they land. Each sub-agent keeps its own tools, its own limits, and its own approval gates.

Delegation as a tool

Calling a sub-agent looks like any other tool call, so the parent's reasoning stays in one place.

Self-contained handoffs

The parent must write a complete task. Sub-agents do not inherit the caller's conversation, which keeps context leakage from becoming a habit.

Synchronous or background

Wait for the answer inline, or dispatch and pick up the output later once the work has run.

No privilege inheritance

A sub-agent runs with the tools it was given, not the ones its caller holds.

Deployment

Four ways out
into the world.

An agent is only useful where the work happens. Each one gets a deploy token when you publish it, and you choose the surface.

Internal only

Runs inside the platform for staff who are already signed in. The default, and the right answer more often than people expect.

API endpoint

Post a message with the agent's deploy token and get a response. Rate limited per agent, logged like every other run.

Standalone chat page

A hosted chat page addressed by the deploy token, with its own welcome message and avatar. Revoking the token turns it off.

As a workflow node

Drop the agent onto the Symphony canvas and it becomes a step in a larger process, supervised by the Conductor and visible while it runs.

Get started

Stand up an
agent live.

Book a demo and bring a task somebody on your team does every week by hand. We will build the agent, give it exactly the tools that task needs, gate the risky step, and run it while you watch the trace.

Book a demo → See Symphony →

✓ Tools assigned, never assumed

✓ Risky actions stop for a human

✓ Every step reconstructable

Reason, act,observe, repeat.