Theme
AI tools
The four tools
A connected tool sees four tools. Your AI decides when to call them; this page is what it's choosing between, and what you can ask it to do explicitly.
get_context
Get the rules that apply to a piece of work. The one to use before writing anything.
| Takes | |
|---|---|
task | What's being done — "write a retainer proposal for Acme" |
client | Optional. If omitted, Vythos reads the client from the task text |
categories | Optional. Narrow to particular kinds of rule |
budget_tokens | Optional. How much context to return |
Returns the rules that bear on the task, in precedence order, with their values and an honest account of what was left out — alongside who your agency is and the clients the key's owner may know about. See What your agent receives.
"Get the Vythos context for a proposal for Acme, then draft it."
check_draft
Check a draft against the rules it was given. Takes the draft text and the pack identifier from get_context.
What it reports:
- Words a rule bans, citing the rule that bans them.
- Payment terms that contradict the rule handed over.
- How much of the pack could be checked, and what couldn't, by name with the reason.
What it doesn't do:
- It doesn't block anything. It's a second pair of eyes, not a gate.
- It doesn't mean compliant. A clean result means nothing was found among the things that can be checked — which today is banned words and payment terms. The result says so in those words, and names what went unchecked.
- It checks against the version the writer was given, not today's. A rule that changed mid-task doesn't retrospectively fail a draft.
"Check that draft against Vythos before I send it."
See Values for what can and can't be checked.
search_memory
Find what happened. For discovery questions: what was quoted last time, what feedback a client gave, what a brief said.
| Takes | |
|---|---|
query | What to look for |
client | Optional |
time_range | Optional |
limit | Optional |
Searches the memory of the person whose connection it is, and returns passages with the document they came from, its date where known, and a confidence signal. When confidence is low the tool is told to say it doesn't have reliable information rather than cite a weak match.
For anything your Playbook governs — rates, terms, brand rules, process — the right tool is get_context, not this one.
log_outcome
Record what happened, and what was followed. After a proposal goes out, a client responds, or terms are agreed.
| Takes | |
|---|---|
type, content | What kind of outcome, and what happened |
client, entities | Optional |
pack_id | The pack this work came from |
followed | The rules actually relied on |
departed | Rules knowingly not followed, each with a reason |
The outcome goes into that person's memory and is searchable immediately. It never becomes a rule — what an agent reports is evidence, not governance.
The followed and departed lists are how you find out which rules are real. A rule that everyone departs from, with reasons, is usually a rule that's out of date.
"Log the outcome in Vythos: proposal sent, followed the rate card and Acme's terms, departed from the 21-day payment rule because they're on 45."
Getting your tool to use them
Most tools call them on their own once connected. If yours doesn't, be explicit — "use Vythos to get the rules first" — and put a line in whatever passes for your tool's standing instructions:
Before writing anything for a client, fetch context from Vythos and follow the rules it returns. Check the draft with Vythos before showing it to me. Quote figures exactly as the rules state them; never calculate new ones.