Skip to content

The Stalwart user guide

This guide is for two kinds of reader: the people who build AI agents with Stalwart, and the people who answer for what those agents do, such as a security, risk or compliance team. It explains what each Stalwart Agents product does, how to use it, and, just as importantly, where each of its guarantees stops.

The guardrail

The guardrail checks every tool call an LLM agent makes before it runs, whichever framework the agent was built with, and answers allow, ask the person, or refuse, naming the rule. Nothing in it is guessed by a language model.

Learn More

The developer products

For teams that build AI agents, an API key gives six more products. The guide calls them by the same names as the website and the API reference.

  • The Bot Builder builds an AI agent of your own from the tools your business already has. You describe the agent in one file, and your rules are checked on every tool call before it runs.
  • Agent Graph Verification checks every route through an agent, or a team of agents, before it goes live. It reports each route that reaches a tool without the check it should pass, the confirmation it should ask for, or the step that should come first.
  • The Guardrail Bug Hunter finds every way through your guardrails to an action they were meant to stop. It shows each one happening, and hands you a fix it has already tested by scanning again.
  • Guardrail Verification answers whether an action can ever happen without the condition that should guard it, for one question or a whole table of them. If it can, you get an example of how and a repair; if it cannot, you get a certificate that proves it.
  • Guardrail Writing turns a rule written in plain words into a guardrail policy. Your own model writes the draft; Stalwart then checks it and repairs it where it is wrong.
  • Random Forest Verification checks a trained random forest model for robustness, monotonicity, fairness and reachability. It can also start from real records and search for the smallest change that would flip a decision.

Language support

The selector reads turns written in English and in Brazilian Portuguese (pt-BR). The language is chosen, never guessed from the turn: the console's Settings page (Language the selector reads), language on a plan request, or the settings.language of your vocabulary file; with none of them, English. A Portuguese turn may be typed with its accents or without them. European Portuguese is not a grammar the selector has, and a turn in any other language is unread.

One agent, in one file

You don't need to learn an agent framework to use any of this. A team puts the products to work through a single agent, described in one file: its tools, its rules, and which changes undo which. Before the agent runs, every route through it is checked. While it runs, every message is read and every tool call is checked, on your own machine. And if a run fails halfway, its changes are undone, the last one first. This is the shop agent the guide uses throughout Part I:

# The shop's support desk, and the billing desk it hands refunds to.
agents:
  desk:
    model: "anthropic:claude-sonnet-5-5"   # your provider; the key comes from your environment
    tools: [get_order, charge_card, send_receipt, read_inbox]
    hands_off_to: [billing]
    on_unread: refuse                      # a turn no tool covers is refused, by name
  billing:
    privilege: high
    tools: [refund_card]
tools:
  - python: shop.tools                     # every public function of shop/tools.py
rulebook: ./policy.co                      # the rules every call is checked against
facts:                                     # what the rulebook's $card_on_file and $order_paid are
  card_on_file: {from: get_order.card, same: order_id}           # read from get_order's answer
  order_paid: {from: get_order.status == paid, same: order_id}   # for the order the call names
runs: atomic                               # a failed run is undone, last write first
storage: sqlite:///runs.db                 # where runs and waiting confirmations are kept

Part I builds it step by step, using only the words in the file above.

Where to start

  • If you only read one page: the whole guide, summed up on a single page.
  • Quickstart: about fifteen minutes, in the console alone, with no key and no terminal. You start a bot from a template, try it, and run it on your own computer.
  • Developer quickstart: about half an hour. You make an account, build a small shop's support bot, check it cannot be misused, talk to it, scan a guardrail policy for holes, and check a proof yourself.
  • What this service does, and what it does not claim: chapter 1. Read its second half before you quote a result to anyone.

The guide has five parts: the Bot Builder, the Bot Builder's selector, the Guardrail Bug Hunter, the hunter and the selector together, and verification and writing. If you work in governance or security, chapter 39 is for you: it shows what each product covers in the 2026 OWASP Top 10 lists and the NIST AI Risk Management Framework, and what such a mapping does not mean. The appendix has the reference tables, the glossary and the changelog.

Checking our work without us

You don't have to trust us to trust a result. A certificate can be checked with no key, no network and none of our software. The certificate specification explains how to read one, the reference checker is a single file you can read in an afternoon, and the certificate corpus gives you real certificates to try it on.

The guide offline. The whole guide in one file, for reading with no network or for an audit file: English · Portuguese.

Each file's SHA-256 is in SHA256SUMS, so a copy can be checked against the one published here. Links that leave the guide -- the API reference, the website -- need the network, and say so; the offline guide has no search.

Elsewhere

Chapter numbers never change, even when a chapter moves to another page, so an audit file that cites chapter 7 will always point to the same chapter.