---
title: The four tools
description: get_context, check_draft, search_memory and log_outcome — what each one does, what it takes, and what it returns.
---

<span class="vy-eyebrow">AI tools</span>

# 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](/ai-tools/what-agents-receive).

> *"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](/concepts/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.