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. The chat starts without a project. If you want to test the agent against a project’s documents, pick one from the Project scope chip above the composer before your first message — sample files you drop into the chat and previews it produces then land there. It is the test bench for this conversation, not a limit on where the agent can later run, and it locks once you send. Without one you can still attach files as the agent’s sources, but not drop project documents into the chat. Then 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.

You stay in control of the conversation while the agent is working. Stop ends the current turn: work already done is kept — including the partial reply, which stays in the thread marked as stopped by you — and the chat hands back to you. You also don’t have to wait for a reply to keep typing: messages sent while the agent is working are queued and answered together, in order, as soon as the current turn finishes. Both apply to any chat with an agent — the builder and a run session alike.

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), Read gap analyses (read the project’s gap analyses: scope, plan and findings), and Web search (read current public guidance).
• Self-management — Update instructions (draft changes to its own instructions for your approval) and Private database (a small store that persists across runs).
• Communication — Chat (always on, so you can talk to it), Send email, and Request documentation (ask people outside your organisation for evidence the project is missing; see Requesting documentation).

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

Citing its sources

When an agent grounds a claim in something it read during the turn — a framework requirement (via Read frameworks) or a document (via Read documents or a file you attached to the chat) — it cites the source as a footnote chip in its reply. Hover a chip to see the requirement’s official text or the quoted passage from the document; expand it to read the source in full. Citations are checked before the reply is accepted: the agent can only cite requirements and documents it actually read that turn, and requirement text is shown from the framework library itself, never from the agent’s own words.

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), by accepting the builder’s publish card, or with Publish… in the agent’s header, which is available from any of its tabs. The header button is greyed out and reads Nothing new to publish when the draft already matches the published version. 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 — unless you pin an automation to a version. Open the automation, choose a published version under Agent version, and it keeps running that version, with that version’s model and XML schemas, until you change the pin; when a newer version is published, the workflow page says so and offers Update to v3 in one click. The model the agent runs on is part of a version too: choose it from the Model button in the builder toolbar (Default follows your organization’s provider), and publishing freezes it — a version set to a model your provider does not offer will not run, so change the model and publish again. Capabilities are part of a version too: granting or revoking one updates the draft, so it shows up in the version history next to instruction edits, and publishing records the capabilities the agent had at that moment. The skills and rules the agent uses work the same way — writing one, editing it, or adopting and dropping one from your organization’s library updates the draft, and a published agent keeps following the versions it was published with until you publish again. Skills and rules your organization has set for every agent are the exception: they are not part of any one agent’s version, so a change to them reaches published agents straight away — as does switching a skill or rule off, which takes it out of every run immediately.

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.

Opening a run — New session, or Test from the builder — puts you straight into an empty chat: it shows the agent’s name, its description, and any example prompts as chips. The agent doesn’t speak first; nothing runs until you send a message. Clicking a chip copies its text into the composer so you can edit it before sending. You set an agent’s example prompts from the Example prompts button in the builder toolbar — up to four, 200 characters each. Like the name and description, they aren’t part of a version, so changing them never creates a new draft.

While you’re building, Test starts a run pinned to the working draft, so you can watch the agent work before publishing it. It asks which project to run against — pick one, or choose No project to test without one.

Reusing an agent across projects

Agents belong to your organization, not to any one project — the same agent can run in any project (a run picks its project when it starts, or runs with none). To share an agent beyond your organization, its creator can make it available to another organization, which adopts its own copy.