Building custom agents

Regnora lets you build custom agents by chatting with a builder, not by filling in a form or writing prompts. You describe the work you want done; the builder drafts the agent’s instructions and proposes the configuration, and you approve as you go. An agent is defined by a name, a description, markdown instructions, the capabilities it’s allowed, and the outputs it may produce. This guide walks through building one, granting it capabilities, and getting it running.

Built-in and custom agents

Regnora ships system agents for the core flows — they’re managed by Regnora, so you can inspect one and see where it’s wired up, but you can’t edit it. Custom agents are the ones you build yourself for work specific to your team: a particular review, a recurring report, a document-to-document flow. This guide is about custom agents.

Building an agent by chatting

Create a new agent and you land in the builder: a chat on one side, the agent’s configuration on the other. Tell it what you want — “I want an agent that watches my policies for compliance gaps” — and it drafts the agent’s instructions and proposes the rest. As the conversation goes, it surfaces proposal cards in line: a capability it needs (Allow or Deny), a canvas or automation it wants to create (Apply or Dismiss), or a new version of its instructions to publish. Nothing takes effect until you act on the card.

If you’d rather set something directly, the configuration panel is a manual editor: you can edit the name, description, and instructions by hand at any time. The instructions are the agent’s system prompt — what it does, how it decides, what’s out of scope.

Manage: Agents

Capabilities

Capabilities are what the agent is allowed to do when it runs — it has none until you grant them, and the builder requests each one as the work calls for it. They’re grouped into three areas:

• Documentation — Read documents (ground its work in your evidence), Write documents, Create revision (stage changes for diff review), Build canvas (produce an in-browser dashboard), Read frameworks (pull requirement text into its reasoning), and Web search (read current public guidance).
• Self-management — Update instructions (draft changes to its own instructions for your approval), Manage automations (set up its own triggers), Manage calendar, and Private database (a small store that persists across runs).
• Communication — Chat (always on, so you can talk to it) and Send email.

You grant or revoke each capability yourself; the agent can only ever propose, never self-authorise.

Outputs it produces

What an agent can produce follows from its capabilities — a document, a revision staged for review, a canvas, or an email. Everything an agent produces is recorded in its Outputs, and anything that touches your data or reaches the outside world is proposed for a human to approve rather than done silently. See Agent outputs for canvases and the agent database.

Versions: draft and published

While you’re building, the agent is a Draft. When the instructions are ready, publish them — from the editor as Save as v2 (the next version number), or by accepting the builder’s publish card. Published versions are immutable snapshots: v1, v2, and so on, and you can compare versions to see what changed. Automations using the agent pick up a newly published version on their next run, so you can keep refining the draft without disturbing what’s live.

Running an agent

You can run an agent two ways. To run it by hand, use Run on a document — pick a document and select Run now, and the agent works on it immediately. To have it run on its own, wire it to a trigger — see Triggers & schedules.

Reusing an agent across projects

A custom agent starts life in one project. Once it’s published, you can promote it to a template in the agent library — a project-agnostic copy — and then deploy that template into another project to start from a known-good shape rather than rebuilding it.