# Vythos Docs
> How to put your agency’s rules where your AI tools can reach them — and keep them current.
# What Vythos is
Source: https://doc.vythos.tech/getting-started/what-is-vythos
# What Vythos is
Vythos is where your agency's rules live so that people — and the AI tools they
use — work from the current ones.
Your rate card is a file. Your tone of voice is a page someone wrote. Your
payment terms are in a contract template, your approval steps in a process doc.
None of that is wrong. The problem is what happens next: a freelancer quotes
last year's day rate, a proposal goes out at net-30 when that client is on
net-45, and a draft written with an AI tool uses three words your brand
guidelines ban — because the tool had no idea the guidelines existed.
Vythos fixes the reaching, not the writing. You keep your documents where they
are. You tell Vythos which of them are rules. From then on, those rules are
available at the moment work happens.
## How it works, in four sentences
1. **You name the documents that are rules.** A Google Drive file, a Notion
page or a file you upload. That document becomes a rule in your
[Playbook](/concepts/playbook).
2. **Vythos follows the file.** It re-reads each rule's document roughly every
ten minutes. When the wording changes, the rule gets a new version and the
old one is kept.
3. **Everything else you connect becomes memory.** Briefs, notes, emails,
repositories, your website: searchable, never governing. Nothing becomes a
rule on its own.
4. **Your rules reach the work.** Ask questions inside Vythos, or connect
Claude, Cursor or your own agent so they receive the rules that apply to the
task — client rules ahead of house defaults.
## What makes it different from a folder
A shared drive holds documents. It can't tell you which of them still counts,
which client overrides which, or what the current number is — and it certainly
can't tell an AI tool.
Vythos adds four things on top of the documents you already keep:
- **A single current version.** One document, one rule. Replace a rate card
and the old one stands down with its history intact, rather than sitting
beside the new one waiting to be quoted by mistake.
- **Precedence.** A client's rule beats your house default, always, and your
tools are told so explicitly. See [Clients and scope](/concepts/clients).
- **Permissions that reach the tools.** A freelancer's AI tool gets your brand
rules and not your rate card, because you decided that. See
[Your team and their access](/using-vythos/team-and-access).
- **Values that can be checked.** Where a rule states a figure — a day rate,
payment terms, words never to use — a draft can be checked against it. See
[Values](/concepts/values).
## What Vythos is not
- **Not a document store.** Your files stay in Drive, in Notion, on your
laptop. Vythos reads them and keeps the text it read, so it can answer and
compare; it never becomes the place your documents live.
- **Not a writing tool.** It doesn't draft your proposals. It gives whatever
you write with the rules it must respect, and can check a draft afterwards.
- **Not an approval queue.** There is no review workflow to maintain. A rule
exists because someone with the right access pointed at a document.
- **Not a detector.** It doesn't decide for itself which of your documents are
rules. Whether an invoice is governance is not a judgement software should be
making on your behalf. A person names the rule, always.
## Who it fits
Vythos is built for creative and marketing agencies that run on their own
standards — from a solo operator with a rate card and a tone of voice, up to a
team of a dozen where different people need different access.
It fits best when:
- your rules already exist as documents, rather than in one person's head;
- more than one person, or more than one AI tool, needs to follow them;
- you work for several clients whose terms differ from your defaults.
It's a poor fit if nothing is written down. Vythos governs documents; it can't
govern an intention. If you're starting from nothing, write one page — your
rate card — and start there.
## What you need
- A Vythos workspace (you create one with an email address and a password).
- Documents. Google Drive, Notion or files on your computer.
- Optionally, an AI tool that supports MCP — Claude Desktop, Claude Code,
Cursor, Windsurf and others do. See [Connect a tool](/ai-tools/connect).
## Worth knowing before you start
- **Only the workspace owner adds and retires rules today.** Teammates can be
given access to *see* particular kinds of rule, in the app and in their AI
tools. Letting a teammate add rules is coming; the invitation screen says so
where you choose access.
- **Rules can come from Google Drive, Notion or an upload.** Other sources —
your website, GitHub, Gmail — feed memory, not the Playbook.
- **Slack is listed in the app but isn't ready.** Don't connect it yet.
## Next
[Quickstart](/getting-started/quickstart) gets you a workspace with real rules
in it in about fifteen minutes. After that,
[which documents to add first](/getting-started/which-documents-first).
# Quickstart
Source: https://doc.vythos.tech/getting-started/quickstart
# Quickstart
By the end of this page you'll have a workspace holding two or three real
rules, an answer that quotes them, and an AI tool that receives them while you
write.
Have ready: a **rate card**, and one more document your team works from — brand
guidelines, your terms, or how you run a project. They can be in Google Drive,
in Notion, or on your computer.
## 1. Create your workspace
Sign up with your name, work email, a name for the workspace and a password of
at least eight characters. Whoever creates the workspace is its **owner**, and
the owner is the person who adds and retires rules.
::: tip One workspace per agency
Your whole team — and every client you work for — lives in one workspace.
Clients are not separate accounts; they're a scope inside your Playbook. See
[Clients and scope](/concepts/clients).
:::
## 2. Say what you do
The first screen asks for your organisation name, what you do, a one-paragraph
description and the kinds of client you work with.
This isn't a rule — nothing is held to it. It's your workspace's description
of itself, and it travels with every question your team's AI tools ask, so they
know whose work they're doing. Everyone in the workspace gets it; only the owner
changes it, in **Settings**. You can skip it and fill it in later.
## 3. Add your first rule
The second screen asks for a document. Upload your rate card — PDF, Word,
Markdown, a spreadsheet, or any [format Vythos reads](/reference/file-formats).
Vythos reads it and shows you the same card you'll see whenever you add a rule:
- **What it governs** — pick a category. For a rate card that's *Pricing &
rates*. ([Categories](/concepts/categories))
- **Which client is it for?** — leave it on *Every client* for a house rate
card. ([Clients and scope](/concepts/clients))
- **The values Vythos read** — any figures it recognised, such as payment terms
or a day rate. Tick *These values are right* only if they are. A confirmed
value is one your AI tools are held to; an unconfirmed one is advisory.
([Values](/concepts/values))
- **Read the document** — shows the exact text Vythos took from the file. Worth
a look the first time, so you can see what a tool will be working from.
Choose *Add to Playbook*. That document is now a rule, at version 1.
## 4. Connect where your documents live
Go to **Sources** and connect Google Drive, Notion, or both. Two things happen:
- You can add rules by **pointing at files where they already live** — no
uploading, and no copy to keep in step.
- Everything in the folders you sync goes into your memory, so Ask can answer
from briefs and notes as well as from rules.
Uploading works perfectly well on its own. But a rule added from Drive or
Notion updates itself when you edit the document, which is the part people
come back for.
See [Google Drive](/sources/google-drive) and [Notion](/sources/notion).
## 5. Add a second rule from the document where it lives
Open **Playbook** and choose **Add rule**. Two ways in:
- **Paste a link** — the URL of a Google Doc, Sheet, Slide, Drive file or
Notion page. Any normal link from the address bar or a Share button works.
- **Choose from your sources** — browse Drive folders (My Drive and Shared
with me, with search), Notion pages, or the files you've uploaded.
Then the same card as before: what it governs, which client, values, and — if
this document replaces one already in force — a tick to say so.
Add your brand guidelines this way, under *Brand & voice*.
## 6. Ask something
Open **Ask** and try the question you'd actually ask a colleague:
- "What are our payment terms?"
- "What's our minimum project fee?"
- "Summarise our brand voice"
Answers cite the rules they used. Where a rule and an older document disagree,
the rule wins and Vythos says so, which is usually the moment you find a stale
note worth fixing. Follow up as you would with a colleague — *"and for a half
day?"* — and the conversation is kept, so a reload loses nothing. See
[Ask](/using-vythos/ask).
## 7. Connect an AI tool
This is the part that changes how work feels. Open **AI tools**, create a key,
and follow the snippet for your tool — Claude Desktop, Claude Code, Cursor,
Windsurf or anything else that speaks MCP.
From then on, your tool can:
- ask for the rules that apply to a task, with client rules ranked above house
defaults;
- check a draft against the rules it was given, before it goes out;
- record what it followed, so you can see which rules are actually being used.
Step-by-step instructions per tool: [Connect a tool](/ai-tools/connect).
## 8. Change a document and watch the rule follow
The last step is the one that proves the model. Open the document behind one of
your rules — in Drive or Notion — and change a figure. Within about ten
minutes, the rule shows **v2**, with version 1 kept in its history.
Nothing is swapped silently: the rule records what changed and when it was last
read. See [Update a rule](/using-vythos/update-a-rule).
## Where to go next
| You want to… | Page |
|---|---|
| Decide what else deserves to be a rule | [Which documents to add first](/getting-started/which-documents-first) |
| Add a client whose terms differ from yours | [Clients](/using-vythos/clients) |
| Give a colleague or freelancer access | [Your team and their access](/using-vythos/team-and-access) |
| Understand what a tool actually receives | [What your agent receives](/ai-tools/what-agents-receive) |
# Which documents to add first
Source: https://doc.vythos.tech/getting-started/which-documents-first
# Which documents to add first
A rule is a document your work has to respect. Most of what an agency writes
isn't that — it's evidence of what happened, which belongs in
[memory](/concepts/memory), where it's searchable but never binding.
The test: **if someone did the opposite of this document, would it be a
mistake?** If yes, it's a rule. If it would merely be *different*, it's memory.
## The first five
Start here. Most agencies have four of these already, in some form.
| Document | Category | Why it's first |
|---|---|---|
| **Rate card** | Pricing & rates | The most-quoted numbers you own, and the ones most often quoted wrong. Add it even if it's a single page. |
| **Terms of business, MSA or contract template** | Terms & commitments | Payment terms, notice, IP, liability. The things a proposal gets wrong quietly. |
| **Brand voice and tone guidelines** | Brand & voice | Also the one with words to avoid — the rule an AI draft breaks most often, and one Vythos can check for you. |
| **How you run a project** | How we work | Stages, revision rounds, what "done" means. Stops every freelancer inventing their own process. |
| **Who signs off on what** | Who decides | Spend limits and approval stages. Short, and it prevents the most expensive kind of mistake. |
Five documents is a working Playbook. You don't need more to feel the
difference.
## Then, for each client you work for
Client rules override your house defaults for that client, and only for that
client. Add them as you need them, not all at once.
- **Their brand guidelines**, if they gave you any — in *Brand & voice*,
scoped to that client.
- **Their contract**, where the terms differ from yours — in *Terms &
commitments*. This is what stops a proposal going out at your standard
payment terms when that client negotiated different ones.
- **Anything they've told you never to do.** A line in an email is enough if
you put it in a document.
See [Clients](/using-vythos/clients) for how to add one.
## What to leave in memory
Connect these as sources so they're searchable, but don't make them rules:
- **Proposals and pitches.** They record what you offered once, not what you
charge.
- **Invoices.** A number in an invoice is a fact about one job.
- **Meeting notes and emails.** Useful context, frequently out of date.
- **Case studies and finished work.** Evidence, not instruction.
- **Briefs.** They describe a job, not your standards.
Vythos never promotes any of these to rules on its own — however much a
document looks like policy. An invoice states a number with great authority,
and it governs nothing.
## A few judgement calls
**A document that's half rule, half example.** Brand guidelines with a page of
sample copy are fine as a rule — the examples don't hurt. A proposal template
with your terms buried in it is better split: make the terms a document of
their own.
**A rate card per client.** Perfectly normal. Add the house rate card for every
client, then each negotiated one scoped to its client. The client one wins for
that client.
**A document nobody has updated in two years.** Add it if it's still true. If
you're not sure it's true, that uncertainty is exactly what your team is
already working with — and once it's a rule, the date it was last changed is
visible to everyone.
**A policy that lives in a Slack message.** Not yet a document. Paste it into a
one-page doc in Drive or Notion, then name it. It takes two minutes and it's
the only version of it that can be kept current.
## Size and shape
- **One document, one rule.** If a file covers pricing *and* your process,
Vythos files it under one category. Splitting it into two documents gives you
two rules that can be updated and retired separately.
- **Long documents are fine.** Vythos reads the whole file, tables included.
- **Scanned PDFs are not.** A PDF that's a photograph of a page has no text to
read. Re-export it from the original, or retype the page that matters.
- **Naming matters a little.** A rule is titled from the document's first
heading, or from the file's name if it has no heading. "Rate Card 2026"
reads better in a list than "final_v3_ACTUAL".
Next: [The Playbook](/concepts/playbook) — what you've just built, and how
Vythos orders it.
# The Playbook
Source: https://doc.vythos.tech/concepts/playbook
# The Playbook
The Playbook is the list of documents your agency's work has to respect. Each
entry is a **rule**: a document someone pointed at and said "this one counts".
Everything else Vythos holds — briefs, notes, emails, finished work — is
[memory](/concepts/memory). Memory is searched. The Playbook governs.
## What's on the page
**A rail on the left, in two parts.** *Your rules* lists the
[categories](/concepts/categories) that hold house rules. Below it, each
[client](/concepts/clients) you've added, with the rules that apply only to
them. Your rules come first because clients are the exceptions to them.
**A count of active rules** at the top, beside the **Add rule** button.
**A row per rule**, showing:
| On the row | What it means |
|---|---|
| The title | Taken from the document's first heading, or the file's name |
| `v2`, `v3` … | This rule has been amended. No badge means it's still at version 1 |
| Value chips | Figures the rule states — a day rate, payment terms, banned words. A green border means a person confirmed them; a plain border means Vythos read them from the document. See [Values](/concepts/values) |
| A summary line | The opening of the document |
Open a row and you get the document's full text as Vythos reads it, a line
telling you exactly how to update this particular rule, a link to the file
where it lives, and the option to retire it.
**An orange note** appears on a rule whose document can no longer be read — it
was deleted, or access was withdrawn. The rule keeps working; it just stops
following the file until you fix it. See
[When a file can't be read](/using-vythos/unreadable-files).
## Order matters
The Playbook is ordered, and the order is what your AI tools are given:
1. **A client's rules beat your house rules.** Always. If Acme's contract says
45 days and your terms say 30, work for Acme is on 45.
2. **Within a scope, categories rank.** Terms and commitments outrank pricing;
pricing outranks process. Full order in
[Categories](/concepts/categories).
3. **Rules beat memory.** A rule is current and governed. A meeting note is
what someone said once. Where they disagree, Vythos answers from the rule
and tells you the note disagrees, so you can go and fix the note.
## Who can change it
Today, **the workspace owner** adds and retires rules. Teammates can be given
access to see particular categories — which decides what reaches them in Ask
and in their own AI tools — but the Playbook page itself is the owner's.
Where you choose someone's access, the screen says which parts are active, so
nobody is promised something the app doesn't do. See
[Your team and their access](/using-vythos/team-and-access).
## What a rule is made of
| Part | Where it comes from |
|---|---|
| **The document** | A Google Drive file, a Notion page, or a file you uploaded |
| **Its text** | Read from that document, kept so Vythos can answer and compare without opening the file every time |
| **Category** | You chose it when adding the rule |
| **Client** | *Every client*, or one client you picked |
| **Values** | Figures Vythos read from the text, which you can confirm |
| **Version** | 1 when added; +1 each time the document's wording changes |
| **History** | Every past version, kept — nothing is deleted |
## The one-document rule
One document makes one rule. File the same document under a second category and
the first reading stands down rather than joining it, so a document can never
be two competing rules at once.
That constraint is worth designing around: if a file covers both your pricing
and your process, splitting it into two documents gives you two rules you can
update, replace and retire independently.
Next: [A rule is a document](/concepts/rules-and-documents).
# A rule is a document
Source: https://doc.vythos.tech/concepts/rules-and-documents
# A rule is a document
In Vythos a rule isn't text you typed into a box. It's a document you already
have, that someone pointed at.
That has three consequences worth understanding, because they explain most of
how the product behaves.
## 1. The rule points at the file, not at a copy
When you add a rule, Vythos records *which file* it is — the Google Drive file
ID, the Notion page ID, or the name of the file you uploaded. Not the folder
path, not a copy.
So:
- **Renaming the file changes nothing.** The rule still follows it.
- **Moving it to another folder changes nothing.**
- **Editing it updates the rule** — see [Update a rule](/using-vythos/update-a-rule).
- **A different file is a different rule.** Saving "Rate Card 2026" as a new
file beside the old one doesn't update anything. Add the new file and tick
*replaces* on the old one.
## 2. Vythos keeps the text it read
Vythos reads the document and keeps that text with the rule. It has to: an
answer, a comparison or a draft check that had to open your Drive every time
would be slow, and would break the moment you were offline or the file was
briefly unavailable.
What this means in practice:
- Your original file never moves and is never stored as a file. Vythos holds
the text, not the document.
- The text is what a tool sees. Open a rule and you can read exactly what was
taken from the file — tables included, formatting simplified.
- If the file becomes unreadable, the rule keeps working from the text it last
read, and says so.
## 3. Nothing becomes a rule by itself
Connect Google Drive and a hundred documents flow into memory. None of them
becomes a rule. Ask a question, log an outcome from an agent, upload a folder
of contracts — still no rules.
A rule exists because a person with the right access named a document. That's
the only way in.
::: tip Why it works this way
Software can guess which documents look like rules. It cannot know which ones
your agency actually stands behind — and a governance layer that guesses wrong
is worse than none, because everything downstream inherits the mistake with
full confidence. So Vythos doesn't guess. One click by the person who knows is
both faster and correct.
:::
## What can be a rule
| Source | Can be a rule | Notes |
|---|---|---|
| Google Drive file | Yes | Including Google Docs, Sheets and Slides |
| Notion page | Yes | |
| A file you upload | Yes | Upload it first, then add it from *Your uploads* |
| Website, GitHub, Gmail | No | These feed [memory](/concepts/memory) only |
| Something an AI tool reported | No | Agent output is evidence, never governance |
Readable formats are listed in [File formats](/reference/file-formats). A
folder is not a document: pick the file inside it.
## How a rule gets its name
From the document's first heading if it has one, otherwise from the file's own
name. So a Google Doc starting with "Rate Card 2026" becomes a rule called
*Rate Card 2026*, and a file called `terms-of-business.pdf` with no heading
becomes *Terms of business*.
If a rule's name reads badly in the list, the fix is in the document: give it a
heading, or rename the file.
## What Vythos does with the document
1. **Reads it** with your access, at the moment you add it. If you can't open
it, neither can Vythos, and it says so rather than adding an empty rule.
2. **Files it** under the category you chose, for every client or one client.
3. **Reads any values** it recognises — figures like payment terms or a day
rate. You decide whether they're right. See [Values](/concepts/values).
4. **Watches it** from then on: a light check about every ten minutes, and a
proper read only when the document has actually changed.
Next: [Categories](/concepts/categories).
# Categories
Source: https://doc.vythos.tech/concepts/categories
# Categories
Every rule is filed under exactly one of seven categories. The list is fixed —
you can't add your own — because the categories do real work: they decide
ranking, and they decide access. A freelancer can be given *Brand & voice* and
not *Pricing & rates* only because those are different categories.
## The seven
They're listed here strongest first. That ordering is the ranking Vythos uses
when two rules at the same scope touch the same question.
| # | Category | What belongs in it |
|---|---|---|
| 1 | **Terms & commitments** | Contracts, NDAs, IP and liability, data protection |
| 2 | **Pricing & rates** | Rate card, day rates, payment terms, minimum fees |
| 3 | **How we work** | Delivery standards, SOPs, quality checks, how work moves |
| 4 | **Brand & voice** | Brand voice, tone, positioning, words to use and avoid |
| 5 | **Who decides** | Who signs off on what, approval stages, escalation paths, spend limits |
| 6 | **Strategy** | Direction, priorities, the plan |
| 7 | **Past decisions** | Decisions already made, and why |
::: info Scope ranks above category
A client rule in *Brand & voice* still beats a house rule in *Terms &
commitments*, because scope is checked first. Category ordering decides between
rules **at the same scope**. See [Clients and scope](/concepts/clients).
:::
## Choosing between two that seem to fit
Most documents are obvious. These are the ones that aren't:
**A rate card with payment terms in it** → *Pricing & rates*. Money and the
terms attached to money live together. Keep *Terms & commitments* for the
contract itself.
**A contract template** → *Terms & commitments*, even though it contains
prices. The document is a commitment; the prices in it are an example of one.
**An approval SOP** → *Who decides* if it's about who signs off, *How we work*
if it's about the stages work passes through. If it's genuinely both, put it in
*Who decides*: sign-off is the part that goes wrong expensively.
**Brand guidelines with a words-to-avoid list** → *Brand & voice*. That list is
also the thing a draft check can test, so it's worth adding properly. See
[Values](/concepts/values).
**A positioning document** → *Brand & voice* if it's about how you sound,
*Strategy* if it's about where the business is going.
**"We decided not to take crypto clients"** → *Past decisions*, once it's
written in a document.
## Why the category matters beyond tidiness
- **Access is per category.** Each teammate gets a level for each one, from
full access down to none. A category set to *No access* is never sent to that
person — not in Ask, not to their AI tools.
- **Ranking is per category.** When an AI tool asks for context, rules arrive
in this order, and the tool is told the order is meaningful.
- **Values are per category.** Vythos only looks for the kinds of figure that
make sense for the category — payment terms in *Pricing & rates*, banned
words in *Brand & voice*. See [Values](/concepts/values).
## Changing a rule's category
Add the rule again from the same document and choose the other category. The
old filing stands down and the new one takes over, keeping the rule's history —
one document is always one rule.
## Two rules in the same category
Perfectly normal: a rate card and a "minimum engagement" note can both sit in
*Pricing & rates*. They only conflict if they state the same value differently,
and in that case Vythos refuses to pick a winner and tells your tools the
Playbook disagrees with itself. That's a prompt to retire one of them.
Next: [Clients and scope](/concepts/clients).
# Clients and scope
Source: https://doc.vythos.tech/concepts/clients
# Clients and scope
Every rule has a **scope**: either *every client* — your house default — or one
named client.
This is the single most valuable thing in the Playbook, because it's the thing
people get wrong under time pressure. Your standard terms say 30 days. One
client negotiated 45. Everyone knows that, until the proposal is written at
half past six by someone who wasn't in that meeting.
## How scope works
- **A client rule wins.** For work for that client, their rule replaces your
house rule in the same category. Nothing is merged, nothing is averaged.
- **It wins across categories too.** Scope is checked before category, so a
client's *Brand & voice* rule outranks every house rule, whatever its
category.
- **Where a client has no rule, your house rules apply.** You don't have to
duplicate anything. Add the two or three documents where that client differs.
## Adding a client
Clients are added by hand, on the Playbook page — type the name and confirm.
Vythos does not scan your documents for client names and invent accounts; if a
client exists, it's because someone typed it.
Once a client exists, *Which client is it for?* in the Add rule card offers
them. See [Clients](/using-vythos/clients) for the steps.
## How Vythos knows which client work is for
**In Ask:** from your question. "What are Acme's payment terms?" is recognised
as being about Acme, and their rules come back ahead of your defaults.
**From an AI tool:** the tool can name the client. If it doesn't, Vythos reads
the client out of the task description the same way Ask does.
Matching is against your list of clients, not a guess. An unrecognised name
matches nothing, and an ambiguous one — two clients whose names overlap —
matches nothing rather than picking. Vythos never invents a client, and never
creates one from a mention.
::: warning Naming a client grants nothing
Client detection decides what is *asked for*, never what is allowed. If a
teammate is restricted to one client, naming another returns nothing at all.
Access is checked separately, every time. See
[Your team and their access](/using-vythos/team-and-access).
:::
## When no client is named
Work that names no client gets your house rules only. Client rules are
deliberately left out — an agent writing Acme's brief must not be handed
another client's terms.
But an AI tool is also told, in the same breath, **that an exception exists**:
which client and which category, never what it says. So a tool can say "there
are pricing rules specific to this client — tell me who this is for" instead of
confidently quoting your default.
## Restricting someone to particular clients
When you invite a teammate you can assign them clients. Assign none and they
see every client's rules, within the categories they have access to. Assign one
or more and those are the only client rules that reach them — in Ask and in
their own AI tools.
Useful for freelancers who work on one account, and for contractors you'd
rather not show your whole book to.
## Retiring a client's rules
A client rule is retired like any other, from its row on the Playbook. The
client stays; their rules stop applying. If an engagement ends, retire the
rules that were specific to them — otherwise their terms keep outranking your
defaults for work that mentions their name.
Next: [Values](/concepts/values).
# Values
Source: https://doc.vythos.tech/concepts/values
# Values
A rule is prose, and prose is what people read. But some of what a rule states
is a *value*: 45 days, 25%, 1.5×, "never say synergy". Vythos pulls those out
and keeps them beside the rule, so a tool doesn't have to interpret a sentence
to know the number.
## What gets read, per category
Vythos only looks for values that make sense for the rule's
[category](/concepts/categories):
| Category | Values it looks for |
|---|---|
| **Pricing & rates** | Day rate, payment terms in days, deposit percentage, overage multiplier, which roles a rate covers |
| **Terms & commitments** | Notice period in days, how long data is kept, governing law |
| **Brand & voice** | Words and phrases never to use, wording that must appear, preferred house vocabulary |
| **Who decides** | The role that signs off, the spend above which approval is needed |
| **How we work** | Revision rounds included, lead time in working days |
Anything else stays as prose. That's deliberate: a value only earns its place
if it can be read out of a document unambiguously.
## Confirmed and unconfirmed
When you add a rule, the values Vythos read are shown to you with a checkbox:
**These values are right.**
| | Unconfirmed | Confirmed |
|---|---|---|
| Where it came from | Vythos read it from the document | Vythos read it, and a person checked it |
| On the rule row | Plain chip | Green-edged chip |
| When a draft contradicts it | Flagged as **worth a check** | Flagged as **breaking this rule** |
Nothing is ever blocked either way — the difference is how seriously a
deviation is reported. Confirm what you're sure of, and leave the rest; an
unconfirmed value is still useful, it just doesn't accuse anyone.
::: tip Read the value before you tick
Confirming is a statement that the number is right *and* that it means what its
label says. A rate card line like "overage: 1.5× standard day rate" can be read
as a multiplier of a day rate — which it is — or of an hour, which it isn't.
Ticking a wrong reading makes it authoritative. If a line is ambiguous, the
better fix is to make the document say it plainly.
:::
## What happens when the document changes
The promise is *edit the document and the rule follows* — including its values.
So when the wording changes:
- **The new values come from the new text.** Whatever the document now says is
what the rule now states.
- **Your confirmation survives only while the document still says what you
confirmed.** If every confirmed value is still there, the rule stays
confirmed. If one changed, the rule's values become unconfirmed again — a new
reading nobody has looked at yet — and go back to being advisory until
someone confirms them.
That's the safe direction: a changed number is reported for a look rather than
silently enforced.
## What a draft check actually tests
This is worth being precise about, because "checking a draft" sounds broader
than it is.
**Checked today:**
- **Words never to use** — from *Brand & voice*. A draft containing a banned
word is reported, citing the rule that bans it.
- **Payment terms in days** — from *Pricing & rates*. A draft saying "net 30"
or "payable within 30 days" when the rule says 45 is reported.
**Not checked** — reported back as *unchecked*, by name, with the reason:
- Day rates, deposits, overage multipliers, approval thresholds, notice
periods, lead times, revision rounds.
- House vocabulary you prefer (nobody is in trouble for not using it).
- Required wording whose requirement is conditional.
- Any value where two rules disagree — Vythos refuses to enforce a coin toss.
A clean result means *nothing was found among the things that could be
checked*. It does not mean the draft is compliant, and the tool is told so in
those words. More checks are planned.
## Where values are used
- **Draft checks**, as above — see [The four tools](/ai-tools/tools).
- **Context for an AI tool**: values are sent beside the rule's text, each
labelled with what it is, so a tool doesn't have to parse "1.5× the standard
day rate" out of a paragraph and can quote the figure as stated.
- **The rule row**, so you can see the current numbers at a glance without
opening a document.
Next: [Versions and history](/concepts/versions).
# Versions and history
Source: https://doc.vythos.tech/concepts/versions
# Versions and history
A rule starts at version 1 and gains a version each time its document's wording
changes. Old versions are kept, never deleted.
## What makes a new version
| What happened | Result |
|---|---|
| You edited the document's wording | **New version.** The rule shows `v2`, `v3` and so on |
| You renamed or moved the file | Nothing. Vythos notes it looked, and moves on |
| You re-saved the file without changing a word | Nothing. Same text, same version |
| You uploaded the same file again, changed | **New version** |
| You added a *different* file that replaces this rule | This rule is retired; the new document's rule starts its own history |
| You retired the rule and later added the document again | The history carries on — a retired v3 is followed by v4, not a second v1 |
The test is the words, not the timestamp. Vythos checks each rule's document
about every ten minutes, and an untouched file costs nothing. A file that was
touched but still says the same thing changes nothing either.
## What's kept
Every past version keeps its own text, its values, and the moment it stopped
governing. That matters for more than tidiness:
- **A draft is checked against the version its author was given.** When an AI
tool asks for context, Vythos records exactly which rules and which versions
it handed over. If the rule changes while the work is in progress, the check
still judges the draft against what the writer actually had. A checker that
cried wolf about a rule nobody had seen would be ignored within a week.
- **You can reconstruct the past.** What did our terms say in March? The
Playbook can answer that, because nothing was overwritten.
## Dates on a rule
A rule row shows the **document's own date** where it has one — "effective
1 July 2025", taken from the document's text — and otherwise the date the rule
was added. The document's date is the more useful of the two: it's the date
your team would quote, not the day someone got round to adding it.
## Replacing one document with another
Editing a document updates its rule. A *new* document is a new rule, and Vythos
will not silently transfer governance from one file to another.
So when you save this year's rate card as a new file:
1. Add the new file with **Add rule**.
2. Where the card asks, tick **replaces** against the old rate card.
The old rule is retired with its history, the new one takes over, and nothing
in between is ambiguous. If you don't tick it, both stay in force — and Vythos
tells your tools they disagree rather than picking one. See
[Update a rule](/using-vythos/update-a-rule).
::: info Same title, different file
If you add a document whose rule would have the same name and category as one
already in force, Vythos stops and asks whether this replaces it. A same-named
takeover is the one case where silently following the newest file would be
indistinguishable from a mistake.
:::
## Retiring
Retiring stands a rule down. It stops reaching your team and their AI tools
immediately; its text and history remain. See
[Retire a rule](/using-vythos/retire-a-rule).
Next: [Memory](/concepts/memory).
# Memory
Source: https://doc.vythos.tech/concepts/memory
# Memory
Memory is everything else. Briefs, proposals, notes, emails, pages from your
site, files you've uploaded: read, split into passages, and indexed so they can
be found by meaning rather than by exact wording.
Memory answers *what happened*. The [Playbook](/concepts/playbook) answers
*what we do*. Keeping them apart is the point.
## What lands in memory
- Everything from a connected source: Google Drive folders you sync, Notion
pages, your website, GitHub repositories, Gmail labels.
- Every file you upload.
- Outcomes your AI tools report back — "proposal accepted", "client asked for
plainer language".
- **Also the documents behind your rules.** A rule's document is a document
like any other; being a rule doesn't remove it from memory.
::: info What you told Vythos about your agency isn't memory
What you do and who you work for is your workspace's own description of itself.
It isn't evidence and it isn't a rule, so it lives in neither: it's
configuration, shown in Settings, shared with everyone in the workspace, and
sent with every question so a tool knows whose work it's doing. It's never
quoted as policy.
:::
## Memory is private to each person
Each person's memory is their own. Your colleague's uploads are not searchable
by you, and yours are not searchable by them — the workspace owner included.
What *is* shared is the Playbook, filtered by each person's access. That's the
design: one agreed set of rules, and private working material.
## Memory never becomes a rule
Nothing in memory governs anything. It's never promoted, never scored, never
turned into policy. A proposal that quotes a day rate does not change your rate
card; it's a record that a number was once quoted.
Making a document a rule is always a deliberate act. See
[A rule is a document](/concepts/rules-and-documents).
## How Ask uses both
When you ask a question, Vythos gathers:
1. **Rules you're allowed to see** that bear on the question — clients first,
then by category.
2. **Passages from your own memory** that match.
It also knows who your agency is and which clients you've added, and — for a
follow-up — the last few turns of your conversation, so it knows what you're
referring to. None of those is a source of facts.
The answer is written from the rules and the passages, with rules ranked above
documents. Where a
rule and a document disagree — an old email saying 30 days, the rule saying 45
— Vythos answers with the rule and tells you the document disagrees. That's
usually a prompt to go and fix the document.
See [Ask](/using-vythos/ask).
## Freshness
Connected sources are re-read on a schedule: Notion about every 15 minutes,
Google Drive about every 30. When a source has gone quiet for a few rounds,
Vythos checks it less often, and speeds up again when something changes. You
can always sync a source by hand from the Sources page.
When a document changes, its passages are **replaced**, not added to — so a
superseded version can never come back later as an answer.
## Removing things from memory
| What you do | What happens |
|---|---|
| Upload a changed file with the same name | Its old text is replaced |
| Disconnect Notion | Notion's credentials **and everything it put in your memory** are removed |
| Disconnect Google Drive | Access is removed. What Drive already put in your memory stays, and rules whose documents live in Drive stop being able to follow them |
| Delete the workspace | Everything goes: rules, memory, clients, connections, history |
::: warning Disconnecting Drive doesn't undo the reading
If your reason for disconnecting is to remove the content, disconnecting alone
won't do it today — Notion clears its memory on disconnect and Drive doesn't.
Deleting the workspace removes everything. If you need Drive's memory cleared
without deleting the workspace, ask us.
:::
Next: [Add a rule](/using-vythos/add-a-rule).
# Add a rule
Source: https://doc.vythos.tech/using-vythos/add-a-rule
# Add a rule
Open **Playbook** and choose **Add rule**. There are two ways to name a
document, and the rest of the card is the same either way.
## Paste a link
Copy the document's URL from your browser's address bar or its Share button,
and paste it in. Vythos understands:
| Link | Example |
|---|---|
| Google Doc | `https://docs.google.com/document/d/…/edit` |
| Google Sheet | `https://docs.google.com/spreadsheets/d/…/edit#gid=0` |
| Google Slides | `https://docs.google.com/presentation/d/…/edit` |
| A file in Drive | `https://drive.google.com/file/d/…/view` |
| Notion page | `https://www.notion.so/Rate-Card-2026-1a2b3c…` or a `notion.site` link |
You'll need the relevant source connected first, because Vythos reads the
document with your access. A link to a **folder** is refused, with a note
telling you to open the file inside it.
## Choose from your sources
Browse instead of pasting:
- **Google Drive** — *My Drive* and *Shared with me*, with folders, breadcrumbs
and a search box that looks up files by name. Files already in your Playbook
are marked, and files in formats Vythos can't read are shown greyed with the
reason.
- **Notion** — your pages, searchable.
- **Your uploads** — everything you've uploaded, from the Sources page or
during setup.
Very large folders are listed up to a limit and say so; use search rather than
scrolling.
## The card
Once a document is chosen, Vythos reads it and shows one card.
**What it governs** — the [category](/concepts/categories). Only the categories
you're allowed to add rules to are offered.
**Which client is it for?** — *Every client* for a house rule, or one client.
You can add a new client here without leaving the card. This field is about
whose work the rule governs; it has nothing to do with who may see it. See
[Clients and scope](/concepts/clients).
**The values Vythos read** — any figures it recognised. Tick *These values are
right* only if they are, and only if they mean what their labels say. See
[Values](/concepts/values).
**Replaces** — appears when something else is already in force that this
document might supersede:
- *Also a pricing rule for every client* — both can stay in force. Tick the
ones this replaces, if this is the newer version.
- *Already a rule with the same name, from another file* — you must decide.
Vythos won't let a same-named document quietly take over from another file.
**Read the document** — the exact text Vythos took from the file. Worth opening
the first time you add a document of a given kind, particularly a PDF or a
spreadsheet, to check that what matters came through.
Then **Add to Playbook**. The rule appears at version 1.
## Who can add rules
The workspace owner. The Playbook page is the owner's, so a teammate has
nowhere to add one — and the access levels you can give them say as much where
you choose them. If a teammate has a document that should be a rule, they send
it to you and you add it. See
[Your team and their access](/using-vythos/team-and-access).
## When something goes wrong
| What you see | What it means |
|---|---|
| *That's a folder. Open the file inside it and copy that link.* | You pasted a folder link |
| *Vythos reads links to Google Drive files and Notion pages.* | The link isn't one Vythos recognises — check you copied the whole URL |
| *Google Drive isn't connected. Connect it in Sources first.* | Connect the source, then try again |
| *Vythos can't open that file with your Google account.* | The file isn't shared with the account you connected |
| *'…' is in the bin in Google Drive.* | Restore it, or pick another file |
| *Vythos does not read Google …* / a format refusal | See [File formats](/reference/file-formats) |
| *'…' is empty.* | There's no text to read — a scanned PDF, or an empty document |
| *This document is already a rule.* | The same file is already in your Playbook. To move it to another category, add it again and choose the new one |
| *The document has changed since you checked its values — look again* | Someone edited the file while the card was open. Reopen it so you confirm what it says now |
## After adding
- The rule appears on the Playbook under its category.
- Vythos begins following the document — about every ten minutes. See
[Update a rule](/using-vythos/update-a-rule).
- Your team and their AI tools get it immediately, within the limits of their
access.
# Update a rule
Source: https://doc.vythos.tech/using-vythos/update-a-rule
# Update a rule
You don't edit rules in Vythos. You edit the document, and the rule follows.
Every rule tells you exactly how, in its own row: open a rule and the line
under the text says what to do for that document's source.
## Google Drive and Notion
**Edit the file.** Change the wording in the Google Doc, the Sheet, or the
Notion page. Within about ten minutes the rule shows a new version, and the old
version is kept.
**Or upload a new version of the same file.** For a PDF or a Word file in
Drive, right-click the file → *File information* → *Manage versions* → *Upload
new version*. That keeps the same file, so the rule follows it. Saving the new
document as a *separate* file does not.
::: warning A new file is not an update
`Rate Card 2026.pdf` sitting next to `Rate Card 2025.pdf` is a different
document, and Vythos will not transfer a rule to it on its own — a "v2" in a
folder is as often a draft as a replacement. Add the new file with **Add rule**
and tick that it *replaces* the old one.
:::
## Uploaded files
Upload the file again under the same name, from **Sources → Local Files**. The
new text becomes the next version of the rule.
Only the person who added the rule updates it this way. A colleague uploading a
file that happens to have the same name is uploading *their* file; it doesn't
touch your rule.
## What counts as a change
Vythos compares the words. So:
- **Reworded, re-figured, sections added or removed** → new version.
- **Renamed or moved the file** → nothing changes; the rule follows the file
itself, not its name or folder.
- **Opened, commented on, re-saved with no edits** → nothing. Vythos notices
the file was touched, reads it, sees the same words, and leaves the rule
alone.
## How long it takes
About ten minutes, and never more than that in normal operation — Vythos checks
each rule's document on that cycle. The checks are light, and nothing is re-read
unless the document has actually changed, so this costs your Drive or Notion
account almost nothing.
If you want to see it happen, change a number and watch the rule's version
badge.
## What happens to the values
The new values come from the new text. If everything you had confirmed is still
stated in the document, the rule stays confirmed. If a confirmed value changed,
the rule's values go back to unconfirmed — a new reading nobody has checked —
until you confirm them again. See [Values](/concepts/values).
## What happens to work already in progress
Nothing breaks. When an AI tool asked for context, Vythos recorded which
version of each rule it handed over, and a draft is checked against *that*
version. Your writer is never told off for following the rule they were given.
## If the rule stops following
If Vythos can't read the document any more — deleted, binned, access
withdrawn — the rule keeps working with the text it last read and shows an
orange note explaining why. See
[When a file can't be read](/using-vythos/unreadable-files).
## Rules with no document behind them
Every rule you add points at a document. A workspace that has been running
since before rules were document-backed may still hold one that doesn't — it
has no source link and no update line on its row, and nothing will ever change
it. To put it back under a document, add that document with **Add rule** and
tick that it replaces the old rule.
# Retire a rule
Source: https://doc.vythos.tech/using-vythos/retire-a-rule
# Retire a rule
Retiring says: this is no longer how we work. The rule stops reaching people
and tools straight away, and everything about it is kept.
## How
1. Open the rule's row on the **Playbook**.
2. Choose **Retire**.
3. Confirm. The row warns you that the rule stops reaching your AI tools
immediately, which is the whole point of doing it.
A rule whose document can no longer be read offers the same thing directly from
its orange note — most files that vanish are rules nobody wants any more. See
[When a file can't be read](/using-vythos/unreadable-files).
## What happens
| | |
|---|---|
| **Immediately** | The rule stops being sent to Ask, to your team, and to every connected AI tool |
| **Immediately** | Vythos stops watching its document. Editing the file changes nothing any more |
| **Kept** | Its text, its values, every version, and the moment it stopped governing |
| **Unaffected** | The document itself. Nothing is deleted in Drive, Notion or anywhere else |
## When to retire rather than edit
- **The policy has ended.** You no longer offer that package, that client
engagement is over, the campaign is finished.
- **The document was never really a rule.** It got added in a first flush of
enthusiasm and now clutters the list.
- **The file has gone and won't come back.**
If the policy still exists but has changed, don't retire it — edit the
document, or add the replacement document and tick *replaces*. That keeps one
continuous history instead of a gap. See
[Update a rule](/using-vythos/update-a-rule).
## Bringing one back
Add the same document again with **Add rule**. The rule resumes where it left
off: a rule retired at version 3 comes back as version 4, not as a second
version 1. History stays continuous, which is what lets a past draft still be
judged against the version its author actually had.
## Who can retire
The workspace owner, the same as adding. Retiring is a governance change, so
it goes through the same door.
# When a file can't be read
Source: https://doc.vythos.tech/using-vythos/unreadable-files
# When a file can't be read
Sometimes Vythos checks a rule's document and can't get at it. The file was
binned, the sharing changed, the person who added it left. When that happens,
the rule gets an orange note saying so — on its own row, and counted at the top
of the Playbook so it isn't lost under a category tab.
## What still works
**The rule does.** It keeps the text it last read, and it keeps reaching your
team and their AI tools exactly as before. Nothing is withdrawn on the strength
of a file being missing — a missing file is more often a tidy-up than a
decision.
**What stops** is the following. Until Vythos can read the document again, the
rule won't change when the document does.
## What the note can say
| Note | What happened |
|---|---|
| *The file is in the bin in Google Drive.* | Someone deleted it. It's recoverable from the bin |
| *Vythos can't open that file with your Google account.* | Sharing changed, or it moved to a drive the connected account can't see |
| *Google Drive isn't connected.* | The source was disconnected. Reconnect it in Sources |
| *The Notion connection has expired.* | Reconnect Notion in Sources |
| *The person who added this file is no longer in the workspace…* | Rules are read with the access of whoever added them. Add the document again from your own account |
| *'…' isn't among your uploaded files.* | An uploaded document that is no longer there — upload it again under the same name |
A source that's simply slow, or briefly down, is **not** reported. Vythos only
writes a note for a lasting cause, because a warning that comes and goes is a
warning people learn to ignore.
## The three ways out
The note offers all three:
**Still needed?** Put the file back — restore it from the bin, re-share it, or
reconnect the source. The note clears by itself at the next check, within about
ten minutes. Nothing else to do.
**Replaced by another file?** Add the new document with **Add rule** and tick
that it replaces this one. The old rule retires with its history; the new
document takes over.
**Not a rule any more?** Retire it, straight from the note. See
[Retire a rule](/using-vythos/retire-a-rule).
## How long it stays
Until the cause is fixed. The note records when the trouble started, so the row
shows how long a rule has been out of touch with its document — "can't read
this rule's file (since 14 March)". A rule that has been adrift for weeks is
usually one to retire.
## Avoiding it
- **Keep rule documents in a shared drive** rather than one person's personal
folder, so a departure doesn't take the file with it.
- **Add rules from an account that will still exist next year.** The rule is
read with the access of whoever added it.
- **Don't reorganise by re-creating.** Moving and renaming are free; deleting
and re-uploading makes a new file that no rule is following.
# Ask
Source: https://doc.vythos.tech/using-vythos/ask
# Ask
Ask is the quickest way to find out what your agency's position is. Type the
question you'd ask a colleague:
- *What are our payment terms?*
- *What's our minimum project fee?*
- *What's Acme's notice period?*
- *Summarise our brand voice*
- *What did we quote them last time?*
## What an answer is built from
1. **Your rules** — the ones you're allowed to see, with the relevant client's
rules ranked above your house defaults.
2. **Your own memory** — passages from the documents you've connected or
uploaded.
3. **Who your agency is** — the description in Settings, and the list of
clients you've added. It's context, never quoted as a rule.
4. **The conversation so far** — so a follow-up is understood. It's used to
work out what you mean, not as a source: every fact still comes from 1 and 2.
The answer names what it used, listed under it.
Each question uses one **credit** from the month's allowance. Greetings don't,
and neither does an answer that failed on our side. See
[Plans and credits](/using-vythos/plans-and-credits).
## Conversations
Every question and answer is kept, so leaving the page or reloading it loses
nothing. Your conversations are listed beside Ask, most recent first, and the
last one reopens when you come back.
- **Follow-ups work.** Ask *"What's our senior designer day rate?"*, then
*"and for a half day?"* — the second question is read in light of the first.
So are *"make that shorter"* and *"put it in a table"*.
- **New chat** starts a fresh conversation; nothing from the old one carries
into it.
- **Delete** a conversation from the list, with a confirmation.
- **Your conversations are yours.** Nobody else in the workspace can read
them — not the owner, not a lead. The same goes for your memory.
## Reading and reusing an answer
Answers are formatted — lists, bold figures, tables when you ask for one — and
appear as they're written. Before the first words, the answer shows what it's
doing: *Searching your documents…*, then *Thinking…*.
**Copy**, under each answer, puts it on your clipboard twice over: formatted,
for an email or a document, and as plain text, for Slack or a form. Paste it
wherever it's going and the right one is used.
If you reload or close the page while an answer is being written, it's still
finished and kept — it'll be in the conversation when you come back.
## The rules it follows
Ask is deliberately constrained, because a confident wrong answer about your
own terms is worse than no answer:
- **Only your material.** Nothing from the wider world, no general knowledge
about how agencies usually work.
- **The rule beats the document.** Where a rule and an older note disagree, the
answer comes from the rule — and says the note disagrees, so you can go and
fix the note.
- **Figures are quoted, never calculated.** If your rate card says "£900 a day"
and "overage at 1.5× the standard day rate", Ask gives you both, and says the
arithmetic is yours. It won't hand you an hourly figure that appears in no
version of your Playbook.
- **Gaps are said, not filled.** If no document says how something is invoiced
or who signs it off, the answer says the Playbook doesn't cover that part,
rather than inventing something plausible.
- **Weak matches are hedged.** When the search finds only loosely related
material, the answer says so instead of asserting.
## Clients
Name the client in the question — "What are Acme's payment terms?" — and their
rules are used ahead of your defaults. Vythos matches the name against the
clients you've added; it never invents one, and if two client names are too
similar to tell apart it uses neither rather than guessing. A follow-up keeps
the client — *"and their logo?"* after a question about Acme is about Acme.
Ask also knows the list itself, so *"how many clients do we have?"* is answered
from the clients you've added — the same count as the Clients list, and only
those: a name that appears in a document isn't counted, because documents
mention prospects and past clients too. Someone restricted to particular
clients is told about theirs, and not given the agency's total.
## What Ask is not
- **Not a chat about your industry.** It answers from your material.
- **Not a writing tool.** For drafting with your rules applied, connect your
writing tool — see [AI tools](/ai-tools/overview).
- **Not a way around permissions.** A teammate's Ask only sees what their
access allows. A category they don't have never reaches them.
## For teammates
Everyone in the workspace gets Ask, filtered to their own access and their own
memory. It's the fastest way for a freelancer to check your tone-of-voice rules
without being given your rate card.
::: info When something is withheld
When a category is withheld from someone, their answer doesn't include it, and
doesn't say that it exists. If a teammate tells you Ask can't find something
you know is in the Playbook, check their access on the Members page.
:::
## When an answer looks wrong
1. **Open the rule it cited** on the Playbook and read the document text. Nine
times in ten the document really does say that, and the surprise is useful.
2. **Check the version.** If the document was edited in the last few minutes,
the rule may not have caught up — it follows within about ten minutes.
3. **Look for a second rule saying something different.** Two rules stating the
same value at the same scope is a disagreement in your Playbook, and Vythos
won't resolve it for you. Retire one.
4. **Check the document date.** A rule quoting 2023 terms is a document that
needs an edit, not a bug.
# Clients
Source: https://doc.vythos.tech/using-vythos/clients
# Clients
A client in Vythos is a name that rules can be attached to. Adding one costs
nothing and gives you somewhere to put the two or three documents where that
client differs from your defaults.
## Add a client
On the **Playbook**, use the client rail on the left, or add one from inside
the Add rule card when you're filing a document for them. Type the name and
confirm.
Nothing else is needed. There's no import, no matching, no setup — and Vythos
never invents a client from a document it read.
## Give them their own rules
Add their document with **Add rule** and choose them under *Which client is it
for?*. Their brand guidelines, their signed terms, the list of words their
legal team hates.
From then on, for work that names that client:
- Their rule replaces your house rule in that category.
- Everywhere they have no rule of their own, your house rules apply.
- AI tools are told which rules are the client's, so a tool can say "I'm using
Acme's payment terms, not your standard ones".
See [Clients and scope](/concepts/clients) for how the ranking works.
## Naming them the way your team writes
Use the name people actually type: *Acme*, not *Acme Holdings (EMEA) Ltd*.
Vythos matches the client out of a question or a task description, so the name
that matches most often is the one worth using.
If two clients have names close enough to confuse, Vythos uses neither rather
than picking one. Rename one of them to something distinct.
## Limiting who sees a client
When you invite someone you can assign them clients:
- **Assign none** — they can see every client's rules, within their category
access.
- **Assign one or more** — only those clients' rules reach them, in Ask and in
their own AI tools.
Useful for freelancers on a single account. See
[Your team and their access](/using-vythos/team-and-access).
## When an engagement ends
Retire that client's rules from their rows on the Playbook. The client name
stays — their past decisions are still part of your record — but their terms
stop overriding your defaults for anything that mentions them.
If the client comes back, add the documents again; the rules resume with their
history intact.
# Your team and their access
Source: https://doc.vythos.tech/using-vythos/team-and-access
# Your team and their access
Access in Vythos answers one question: **which kinds of rule reach this
person** — on their screen and, just as importantly, in the AI tools they use.
A category set to no access is never sent to them. Not in Ask, not in a context
pack, not in a draft check. This is what makes it safe to give a freelancer
your brand rules without giving them your rate card.
## Invite someone
Go to **Members** → *Invite team member*:
1. **Email.**
2. **Role** — this sets sensible defaults, which you can then change.
3. **Assigned clients** — leave empty for every client, or pick the accounts
they work on.
4. **Playbook access** — a level for each of the seven
[categories](/concepts/categories).
They get an emailed link. Invitations expire after **7 days**; send another if
one lapses. How many people you can have depends on your plan, shown on the
Members page.
## The four roles
Roles are a starting point, not a cage: every category can be changed
individually when you invite someone, and afterwards.
| Role | Who it's for | What they get by default |
|---|---|---|
| **Owner** | You. The person who created the workspace | Everything, and the only person who adds and retires rules |
| **Lead** | Account or creative lead | Every category reaches them and their AI tools |
| **Member** | Specialist — copy, design, paid media | How we work, brand, strategy and past decisions. Not pricing, terms or who decides |
| **Collaborator** | Freelancer or external partner | How we work and brand only, and only the clients you assign |
## The four levels
For each category, per person:
| Level | What it means today |
|---|---|
| **Can edit** | Adds and retires rules of this kind — **owners only for now**. For anyone else it currently behaves like *Can see* |
| **Can suggest** | Sees these rules. Suggesting changes is coming |
| **Can see** | Sees these rules, and they reach their AI tools |
| **No access** | Not shown, and never sent to their tools |
::: info Why two levels behave the same today
Only the owner has the Playbook page, so *Can edit* and *Can suggest* currently
deliver what *Can see* delivers. The distinction is kept because it's the
access you'll want the day teammates can add rules, and the invitation screen
says this plainly rather than promising something the app doesn't do yet.
:::
## What a teammate sees
- **Ask**, answering from the rules they're allowed and their own memory. Their
conversations are their own — you can't read them, and they can't read yours.
- **Sources**, to connect their own accounts and upload their own files. What
they upload goes into *their* memory — not yours, and not the owner's.
- **AI tools**, to connect Claude, Cursor or anything else with their own key.
Their key carries their access: their tools receive exactly what they do.
They don't see the Playbook page, the Members page, or anyone else's memory.
## Changing access later
On **Members**, open someone's access and change any category. It takes effect
on their next question and their next context pack — there's nothing to
re-issue and no key to rotate.
## When someone leaves
There's no way to remove a person from the workspace in the app today. To stop
anything shared reaching them, open their access on **Members** and set every
kind of rule to *No access* — it takes effect on their next question and their
next context pack — then ask us to close their account.
One thing to know: **rules are read with the access of whoever added them.** If
a departing colleague added rules from their own Drive, those rules keep
working but stop following their documents once that access ends, and say so.
Add the documents again from an account that's staying. See
[When a file can't be read](/using-vythos/unreadable-files).
## Good defaults for an agency
- **Freelancers** → Collaborator, assigned to the one client they work on.
- **Employed specialists** → Member. Add *Pricing & rates* at *Can see* only if
they quote.
- **Account leads** → Lead. They usually need terms and rates to do their job.
- **Your accountant or lawyer**, if you add them at all → Member with
everything at no access except *Terms & commitments*.
# Plans and credits
Source: https://doc.vythos.tech/using-vythos/plans-and-credits
# Plans and credits
Every plan includes your rules, their history, and your AI tools. The plans
differ in three things: how many clients are live, how many people are in the
workspace, and how many **credits** Ask has each month.
| | Free | Solo | Team |
|---|---|---|---|
| Clients | 1 live | No limit | No limit |
| People | 1 | 1 | Everyone on your team |
| Credits a month | 30 | 300 | 1,500, shared |
| AI tools and agents | No limit | No limit | No limit |
Current prices are on [vythos.tech/pricing](https://vythos.tech/pricing).
## What a credit is
**One credit is one question asked on the Ask page.** Each question runs an
AI model, and that costs money every time.
Some things never use a credit:
- **Your AI tools.** When Claude, Cursor or another connected tool fetches your
rules or searches your memory, no credit is used, on any plan. That lookup is
what Vythos is for, so it isn't rationed.
- **A greeting or a thank-you** in Ask.
- **An answer that didn't happen.** A question that couldn't be answered
because something went wrong on our side is given back. So is the reply
Ask gives before you've added any documents.
The count is on the Settings page. It starts again each month: on the 1st on
Free, and on your billing day on Solo and Team.
## When the month's credits are used
Nothing else stops. Your rules, your memory and your AI tools carry on as
normal. Asking on the Ask page pauses until the credits start again, and it
tells you when that is. You can keep asking in any AI tool you've connected
in the meantime.
- **The workspace owner** is offered an upgrade.
- **Everyone else** is asked to talk to the owner, because only the owner can
change the plan.
## One live client on Free
On Free, one client's rules are live: they reach your AI tools and Ask. Any
other clients are **paused**. Their rules are kept, not deleted, and they come
back the moment the workspace moves to Solo or Team. The owner chooses which
client is live on the Settings page.
## Changing plan
Only the workspace owner can change the plan, from **Settings → Billing**.
Moving down doesn't delete anything:
- clients beyond the new limit are paused;
- people beyond it lose access until the plan allows them again.
# Sources overview
Source: https://doc.vythos.tech/sources/overview
# Sources
Connecting a source does one thing: it puts the text of your material into
[memory](/concepts/memory), where Ask can search it.
It does **not** create rules. Rules only exist when a person names a document
on the Playbook page. Connect an entire Drive and your Playbook stays exactly
as it was.
## What each source is good for
| Source | Rules can come from it | Re-read | Good for |
|---|---|---|---|
| [Google Drive](/sources/google-drive) | Yes | ~30 min | Where most agencies keep the documents that are rules |
| [Notion](/sources/notion) | Yes | ~15 min | Teams who write their processes in Notion |
| [Uploads](/sources/uploads) | Yes | On upload | A signed PDF, a one-off document, anything not in a connected tool |
| [Website](/sources/website) | No | On demand | Your own positioning and service pages |
| [GitHub](/sources/github) | No | On demand | Product docs, technical decisions |
| [Gmail](/sources/gmail) | No | On demand | Threads where something was agreed |
The Sources page lists further integrations beyond these. They're in private
preview rather than generally available — tell us which one you need and we'll
say where it stands. Slack is listed there too and isn't ready for use; don't
connect it yet.
## Connections are personal
Each person connects their own accounts, and what a source brings in goes into
*their* memory. Nobody — including the workspace owner — can search anyone
else's.
There's a consequence worth knowing: **a rule is read with the access of
whoever added it.** If the person who added a rule from their Drive leaves the
workspace, that rule keeps working but stops following its document, and says
so on its row.
## How often things are re-read
- **Google Drive** about every 30 minutes, **Notion** about every 15. When a
source has been quiet for a few rounds, Vythos checks less often, and picks
up again as soon as something changes.
- **Documents behind rules** are checked about every 10 minutes, separately and
regardless of source. That's the promise that a rule follows its file.
- **Website, GitHub, Gmail and uploads** happen when you ask for them.
You can always sync by hand from the Sources page.
## Changed documents replace themselves
When a document you've already synced changes, its old text is replaced rather
than added to. A superseded version is gone rather than sitting in the index
waiting to be returned as an answer.
## What to connect first
1. **The place your rule documents live** — Drive or Notion. This is what makes
your Playbook self-updating.
2. **A folder of recent client work** — proposals, briefs, notes. It's what
makes Ask useful beyond the rules.
3. Anything else, later. There's no benefit to connecting everything on day
one.
# Google Drive
Source: https://doc.vythos.tech/sources/google-drive
# Google Drive
Drive is where most agencies keep the documents that become rules, so this is
usually the first source to connect.
## Connect it
**Sources → Google Drive → Connect.** You'll sign in with Google and grant
access. Then pick the folders to sync: browse *My Drive*, open folders, tick
the ones you want, and sync.
You're connecting **your** Google account. Your colleagues connect their own.
## What gets synced
Every readable file in the folders you chose, including subfolders. Google
Docs, Sheets and Slides are read in full, with their structure intact — a
document keeps its tables, a spreadsheet keeps its rows. See
[File formats](/reference/file-formats) for what's readable and what's skipped
by name.
Files Vythos can't read aren't silently dropped; they're reported with the
reason.
The text goes into your memory. **No file becomes a rule** because it was
synced.
## Making a Drive document a rule
Two ways, both on the Playbook page under **Add rule**:
- **Paste its link** — any Drive or Docs URL.
- **Choose from your sources → Google Drive** — browse *My Drive* and *Shared
with me*, or search by file name. Files that are already rules are marked.
A rule's document doesn't have to be in a synced folder. The rule points at the
file itself.
## Keeping a rule current
Edit the document and the rule follows within about ten minutes. For a PDF or
Word file, use Drive's **Manage versions** (right-click the file → *File
information* → *Manage versions*) so it stays the same file. A new file with a
new name is a new document — add it and tick *replaces*. See
[Update a rule](/using-vythos/update-a-rule).
## Shared drives and shared files
Both work. *Shared with me* is browsable when adding a rule, and shared drives
are supported. What matters is that the account you connected can open the
file: rules are read with your access, so a file shared with you personally
stops being readable if that sharing is withdrawn.
For anything important, keep the document in a shared drive rather than a
personal folder.
## Syncing again
Automatically, about every half hour, slowing down while nothing changes and
speeding up when it does. You can also sync by hand from the Sources page.
Documents behind rules are checked more often — about every ten minutes —
whether or not they're in a synced folder.
## Disconnecting
Removes Vythos's access to Drive. Two things to know:
- **What Drive already put into your memory stays.** If your aim is to remove
that content, deleting the workspace removes everything; ask us if you need
Drive's memory cleared on its own.
- **Rules whose documents live in Drive stop following them**, and say so on
their rows. They keep working with the text last read.
## Troubleshooting
| Problem | Fix |
|---|---|
| *Vythos can't open that file with your Google account* | The file isn't shared with the connected account, or it moved to a drive that account can't see |
| A rule stopped updating after someone left | Rules are read with the adder's access. Add the document again from an account that's staying |
| A file didn't sync | Check the format list. Legacy `.doc`, `.xls`, `.ppt`, Pages, Numbers, Keynote and scanned PDFs aren't readable |
| The folder list is huge | Use the search box when adding a rule; listings are capped and say when they've been cut short |
# Notion
Source: https://doc.vythos.tech/sources/notion
# Notion
If your processes and brand guidelines live in Notion, connect it and they can
be rules that update themselves as you edit the page.
## Connect it
**Sources → Notion → Connect.** Notion asks which pages to share with Vythos —
Vythos can only ever see what you grant there. Back in Vythos, select the pages
to sync and start the sync; progress is shown as it runs.
## What gets synced
The text of the pages you selected, into your memory. **No page becomes a rule
by being synced.**
## Making a Notion page a rule
On the Playbook page, **Add rule**, then either:
- **Paste the page link.** Copy it from Notion's *Share → Copy link*, or from
the address bar. Both the long slug-and-id form and the short `notion.so/…`
form work, as does a published `notion.site` link.
- **Choose from your sources → Notion**, and search your pages.
## Keeping it current
Edit the page. Within about ten minutes the rule takes the new text as its next
version, keeping the old one. Nothing to press.
## What to expect from the text
Vythos reads the page's content as text. Rich blocks flatten sensibly: headings
stay headings, lists stay lists, tables come through as rows. Before adding an
elaborate page as a rule, use **Read the document** on the Add rule card to see
what Vythos actually took.
Sub-pages are separate pages in Notion, and separate documents here. If the
rule lives on a sub-page, name that sub-page.
## Disconnecting
Disconnecting Notion removes its access **and everything it put in your
memory**, along with the record of what was synced. Rules made from Notion
pages keep working from the text last read, and say on their rows that the page
can no longer be read.
## Troubleshooting
| Problem | Fix |
|---|---|
| A page can't be found when adding a rule | It probably wasn't shared with Vythos in Notion's connect dialogue. Re-run the connection and include it |
| *The Notion connection has expired* | Reconnect Notion in Sources; rules start following their pages again at the next check |
| The rule text is missing part of the page | Check for sub-pages or synced blocks — they're separate pages, and each is its own document |
# Uploads
Source: https://doc.vythos.tech/sources/uploads
# Uploads
Some documents aren't in a connected tool: a signed PDF, an exported deck, a
contract someone emailed you. Upload them.
## Sync a folder from your computer
**Sources → Local Files → Select folder.** Choose a folder; Vythos scans it,
reads every supported file, and reports anything it skipped and why.
Come back later and select the same folder, and only what changed is uploaded
again — Vythos remembers which files it has seen and how big they were.
::: warning Chrome or Edge only
Selecting a folder uses a browser feature that only Chromium browsers support.
In Safari or Firefox the page says so. Everything else in Vythos works in any
modern browser.
:::
## Upload a single document
During setup, the *first rule* step takes one file and walks you straight into
adding it as a rule. Afterwards, upload from Local Files and then add the
document on the Playbook page.
## Making an uploaded document a rule
**Playbook → Add rule → Choose from your sources → Your uploads.** Search by
name; everything you've uploaded is there.
## Keeping an uploaded rule current
Upload the file again, under the same name. The new text becomes the rule's
next version, immediately — there's no waiting, because you've just handed
Vythos the new document.
Two things to know:
- **The name is the identity.** `rate-card.pdf` uploaded again updates the
rule; `rate-card-v2.pdf` is a different document. To swap to a
differently-named file, add it and tick *replaces*.
- **Uploads are personal.** If a colleague uploads a file with the same name,
it's their document in their memory. It cannot overwrite your rule.
A document that lives in Drive or Notion is better added from there — then it
updates when you edit it, with nothing to remember.
## What can be uploaded
Every format in the [file formats list](/reference/file-formats): PDF, Word,
Excel, PowerPoint, Markdown, plain text, CSV, TSV, HTML, JSON and RTF.
A file Vythos can't read is named with the reason rather than silently
dropped — legacy `.doc`, `.xls` and `.ppt`, Pages, Numbers and Keynote files,
images, video, audio and archives.
Single documents during setup are limited to 20 MB. A scanned PDF — pictures of
pages with no text layer — has nothing to read; re-export it from the original.
## Where uploads go
Into your own memory, and nowhere else. Your colleagues can't search your
uploads, and neither can the workspace owner. Making one a rule is what makes
its *content* available to the people whose access covers that category.
# Website
Source: https://doc.vythos.tech/sources/website
# Website
Your site is where your positioning is already written down. Adding it makes
your own words searchable — useful when someone asks how you describe a service
or what you claim publicly.
## Add a site
**Sources → Website**, paste the address, and start. Vythos finds the site's
pages — from its sitemap where there is one, otherwise by following links
within the same domain — reads the main content of each, and puts the text into
your memory.
By default it takes up to **30 pages**, and never more than 100. It stays on
the one domain, crawls politely with a pause between requests, and respects
`robots.txt`.
## What it's for, and what it isn't
**Good for:** your service descriptions, your about page, published case
studies, your public FAQ.
**Not a rule source.** Pages from a website can't become rules. A website is a
description of what you sell, written for buyers; your rules are the documents
your team is held to, and they should come from Drive, Notion or an upload.
**Not for other people's sites.** Nothing stops you crawling a public site, but
memory is for material you're entitled to use, and your own words are what
make answers about your agency correct.
## Keeping it fresh
Crawls happen when you ask for them. Re-run the crawl after a site redesign or
a repositioning; pages that changed replace their old text.
## Troubleshooting
| Problem | Fix |
|---|---|
| Very few pages found | The site may have no sitemap and little internal linking. Add key pages individually |
| A page's text looks thin | Heavy JavaScript rendering can leave little for a crawler to read. Paste the copy into a document and upload it instead |
| The crawl stopped early | Page limits apply — raise the limit, or crawl a section at a time |
# GitHub
Source: https://doc.vythos.tech/sources/github
# GitHub
For teams whose work includes building things, GitHub holds decisions that
never make it into a document: why an approach was chosen, what a client asked
for mid-sprint, how a component is meant to be used.
## Connect it
**Sources → GitHub → Connect**, and authorise with your GitHub account. Vythos
lists the repositories you can see; choose the ones to sync.
## What gets synced
- **Documentation** — the repository's README and the Markdown in its `docs/`
folder.
- **Issues** — titles and descriptions, most recently updated first, open and
closed.
The text goes into your memory, where Ask can search it. Nothing from GitHub
becomes a rule.
## When it's worth connecting
- You maintain a product alongside client work and want its decisions
searchable.
- Your delivery process lives in a repository rather than in Notion.
- Client feedback arrives as issues.
If your repositories are only code, the value is small: Vythos reads prose, not
source files.
## Syncing again
On demand, from the Sources page. Re-syncing replaces what changed rather than
duplicating it.
## Access and privacy
Vythos sees what the account you connected can see. Private repositories stay
private: their text goes into **your** memory, which nobody else in the
workspace can search.
Disconnecting removes Vythos's access to GitHub.
# Gmail
Source: https://doc.vythos.tech/sources/gmail
# Gmail
A great deal of what an agency agrees happens in email: a rate accepted, a
deadline moved, a client saying never to use that photograph again. Syncing a
label makes those threads searchable.
## Connect it
**Sources → Gmail → Connect**, and sign in with Google. Vythos lists your
labels; choose one and sync it, over a window of recent days that you set —
30 by default.
## Sync a label, not an inbox
This is the part worth doing deliberately. Rather than connecting everything,
make a label — `Clients/Agreed`, `Vythos`, whatever suits — and apply it to the
threads that actually matter.
Reasons:
- **Relevance.** An inbox is mostly noise, and noise makes search worse.
- **Privacy.** Only what you label is read.
- **Control.** Remove the label from a thread and stop syncing it, rather than
reasoning about an entire mailbox.
## What it's for
Memory, and only memory. Email cannot become a rule, and it should never want
to be one: an agreement in an email is a fact about one client at one moment,
and Vythos will answer from your rules over an email every time.
If an email contains something that genuinely is policy, write it into a
document and make *that* a rule.
## What's read
The text of messages under the label you chose, within the window you set, into
your own memory. Nobody else in the workspace can search it — the workspace
owner included.
## Syncing again
On demand, from the Sources page. Choose the label and the window each time;
messages already read are not duplicated.
## Disconnecting
Removes Vythos's access to Gmail. What was already read stays in your memory;
deleting the workspace removes everything.
# AI tools overview
Source: https://doc.vythos.tech/ai-tools/overview
# AI tools
A capable AI tool with no idea what your agency charges will write a confident
proposal at a made-up rate. Not because it's careless — because nobody told it.
Connecting your tools to Vythos tells it. Your rules travel to the place the
work is being written.
## What a connected tool can do
| It can | What that means in practice |
|---|---|
| **Ask for the rules that apply to a task** | "Write a proposal for Acme" returns Acme's terms ahead of your defaults, with the current version of each |
| **Check a draft before it goes out** | Words your brand rules ban, payment terms that contradict the rule it was given — each reported with the rule it breaks |
| **Search your own memory** | "What did we quote them last time?" — from your material, not from guesswork |
| **Report what it did** | Which rules it followed, and where it knowingly departed and why |
## How it connects
Through **MCP**, the Model Context Protocol — the way AI tools connect to
outside systems. Anything that speaks MCP can connect: Claude Desktop, Claude
Code, Cursor, Windsurf, custom agents.
You don't need to know the protocol. In the app, **AI tools** gives you the
address and a ready-made snippet per tool. See
[Connect a tool](/ai-tools/connect).
## What the tool receives
Not your whole Playbook. The rules that bear on the task, for the client named,
within the access of the person whose key it is, ordered so the tool knows
which beats which — plus the values stated as values, a note of anything
relevant that was left out, and who your agency is and which clients you have.
See [What your agent receives](/ai-tools/what-agents-receive).
## What it can't do
- **See past permissions.** A key carries the access of the person who made it.
A freelancer's tool gets what the freelancer gets.
- **Change your Playbook.** Nothing an agent reports becomes a rule. Ever.
- **Reach another person's memory.** Memory is private to each person, and a
key doesn't widen that.
## What changes for you
The visible change is fewer corrections: fewer proposals at the wrong rate,
fewer drafts using the three words a client hates.
The less obvious one is that you can see which rules are actually being used.
When a tool reports what it followed, and what it deliberately departed from
and why, you learn which rules work and which ones everyone quietly routes
around — usually because they're out of date.
## Getting started
1. [Connect a tool](/ai-tools/connect) — five minutes per tool.
2. Ask it to do a real piece of work for a named client.
3. Ask it to check the draft before you send it.
# Connect a tool
Source: https://doc.vythos.tech/ai-tools/connect
# Connect a tool
Everything you need is on the **AI tools** page in Vythos: the server address,
a key, and a ready-made snippet per tool. Copy from there rather than from
here — the address is shown to you rather than hard-coded, so it's always the
right one for your workspace.
::: tip Two ways to prove who you are
**Claude Desktop** signs in with your Vythos account (OAuth): no key to paste
or keep safe. **Everything else** uses a key sent as an
`Authorization: Bearer …` header. Either way, the connection carries the access
of the person it belongs to.
:::
## Claude Desktop
1. In Vythos, open **AI tools** and copy the server address.
2. In Claude Desktop: **Settings → Connectors → Add → Custom connector**.
3. Paste the address and choose **Connect**.
4. Your browser opens. Sign in to Vythos and approve.
No key needed. The connection appears on the AI tools page, where you can see
when it was last used.
## Claude Code
1. In Vythos, **AI tools → New key**, give it a label such as `Claude Code`,
and copy both the key and the address.
2. Run the command shown on the page:
```bash
claude mcp add --transport http vythos \
--header "Authorization: Bearer "
```
Use `--transport http`. The address ends in `/sse` for historical reasons, but
the server speaks Streamable HTTP — `--transport sse` fails to connect.
## Cursor
Create or edit `.cursor/mcp.json` in your project root:
```json
{
"mcpServers": {
"vythos": {
"url": "",
"headers": { "Authorization": "Bearer " }
}
}
}
```
## Windsurf
**Settings → MCP**, or edit `~/.codeium/windsurf/mcp_config.json` with the same
shape as Cursor's config above.
## Any other MCP client
Three values, and every MCP client needs them:
| | |
|---|---|
| **Server URL** | From the AI tools page |
| **Transport** | Streamable HTTP (POST) |
| **Auth header** | `Authorization: Bearer ` |
Most tools that advertise MCP support work with this. The ones listed on the
AI tools page are the ones we've connected ourselves.
## Check it worked
Ask your tool to do something that needs your rules:
> "Using Vythos, what are our standard payment terms?"
or, better, a real task:
> "Draft a project proposal for Acme for a three-month retainer. Get the rules
> from Vythos first, and check the draft before you show it to me."
You should see the tool call Vythos, quote figures that match your Playbook,
and — on the check — either report nothing found or name the rule a line
breaks.
## If it doesn't connect
| Symptom | Likely cause |
|---|---|
| The client can't reach the server | Check the address is exactly the one on the AI tools page, including `/sse` |
| Connects, then every call is rejected | The key is wrong, revoked, or missing its `Bearer ` prefix |
| Claude Code connects then drops | You used `--transport sse`. Use `--transport http` |
| Connects but returns nothing useful | Check the access of whoever owns the key. A category set to no access is never sent |
| The address keeps changing | Your workspace is pointed at a temporary development address. The AI tools page says when that's the case — ask us for the permanent one |
## Keys and hygiene
A key is shown **once**, when you create it. Keep it where you keep other
secrets, one key per tool, and revoke any you're unsure about — revoking takes
effect immediately. See [Keys](/ai-tools/keys).
# What your agent receives
Source: https://doc.vythos.tech/ai-tools/what-agents-receive
# What your agent receives
When a tool asks Vythos for context, it doesn't get your Playbook. It gets a
**pack**: the rules that bear on this task, for this client, within the access
of the person whose connection it is — ordered, with the values stated
separately, and honest about what it left out.
You don't have to read this page to use Vythos. It's here because the answer to
"what did my AI tool actually know?" should be inspectable.
## What's in a pack
**Who your agency is.** The description from Settings — what you do, who
for — labelled as context, not a rule, so a tool knows whose work it's doing
without quoting your self-description as policy.
**Your clients.** The names of the clients you've added, active and dormant,
with exact counts — the names `client` accepts, and the answer to "how many
clients do we have?", which no document states. For someone restricted to
particular clients, only theirs, and the tool is told not to state a total.
**The rules.** Each one with its identifier, category, title, whether it
applies to every client or one, its version number, its text, its rank, and its
values.
**The values, resolved.** Where several rules state the same kind of value, the
one that governs is resolved and handed over, labelled with what it is: not
`1.5` but *1.5× the standard day rate*, not `45` but *45 days*. Where two rules
at the same scope disagree, no value is resolved — the pack reports the
disagreement rather than picking.
**Passages from memory** that match the task.
**The order**, stated explicitly, so a tool doesn't have to infer it: client
rules first, then house rules by category.
**What must be cited.**
**A pack identifier**, used to check a draft later and to report what was
followed.
## What it says about its own gaps
This is the part that matters most, and the part most systems skip.
| Signal | What it tells the tool |
|---|---|
| **No rules found** | "No governed context available. Acknowledge the gap before proceeding" — so the tool says it's improvising rather than sounding authoritative |
| **No client-specific rules** | "Proceed with agency defaults. No client-specific rules found" |
| **A client exception exists but wasn't asked for** | Which client and which category has its own rule — **never what it says**. Enough for the tool to ask "who is this for?" instead of quoting your defaults as universal |
| **Rules omitted for size** | How many were left out, and to ask for a bigger budget or fewer categories before relying on the pack |
| **Rules sent as values only** | When a pack is tight, a rule can arrive as its values without its full wording. It still binds, and the tool is told to search for the text if it needs it |
| **Figures present** | "State each figure in the unit its key names, and do not calculate new figures from them" |
That last one matters more than it looks. A rule stating *1.5× the standard
day rate* is easy to quote correctly and then multiply into an hourly figure
that appears in no version of anything — stated with exactly the same
confidence as the figure it came from. A derived number is the easiest way for
a governance layer to make things worse, so tools are told to hand over the
figures and the rule, and leave the arithmetic to a person.
## What is never in a pack
- **Rules in categories the connection's owner can't see.** They aren't
filtered on the way out; they were never gathered.
- **Other clients' rules** when a client is named.
- **Another person's memory.**
- **Another client's rules**, or anything they say. The client list carries
names, never rules.
- **For someone restricted to particular clients: the other clients at all.**
Not their rules, not their names, not that an exception exists — nothing
that reveals them.
## Size
A pack has a token budget — about 12,000 by default — and a tool can ask for
more or narrow the categories. Rules are packed in precedence order, so if
anything has to be left out it's the least authoritative, and the pack says
what went.
## Seeing it for yourself
Ask your connected tool to fetch context for a task and show you what came
back. Every field above will be there, including the gap signals, and it's the
quickest way to understand what your tools are actually working from.
Next: [The four tools](/ai-tools/tools).
# The four tools
Source: https://doc.vythos.tech/ai-tools/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](/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.
# Keys
Source: https://doc.vythos.tech/ai-tools/keys
# Keys
Most tools authenticate with a key. Claude Desktop is the exception: it signs
in with your Vythos account instead, and needs no key at all.
## Create one
**AI tools → New key.** Give it a label naming the tool it's for — `Cursor`,
`Claude Code`, `agency bot` — and copy it.
The key is shown **once**. Vythos keeps only a hash of it and the first few
characters, so the page can show you `vyk_live_abc…` in the list. Nobody at
Vythos can read your key back to you; if you lose it, revoke it and make
another.
## What a key carries
**The access of the person who created it.** Not the workspace's access —
theirs. A freelancer's key reaches exactly what the freelancer reaches: the
categories they're allowed, and the clients they're assigned.
That has a useful consequence: to change what a tool can see, change that
person's access on the Members page. Nothing to re-issue.
A key does **not** let a tool:
- see another person's memory;
- add, change or retire a rule;
- act outside the workspace it was made in.
## Use one
Send it as a header:
```
Authorization: Bearer vyk_live_…
```
Per-tool configuration is on [Connect a tool](/ai-tools/connect).
## Look after it
- **One key per tool.** Then revoking one doesn't disturb the others, and
"last used" tells you which tool is actually working.
- **Treat it like a password.** Don't paste it into a shared document, a ticket
or a chat.
- **Keep it out of your repository.** A key in `.cursor/mcp.json` that gets
committed is a key you should revoke. Use your tool's secret handling, or
keep the file out of version control.
- **Revoke on a change of hands.** When a freelancer finishes, revoke their
keys as well as their access.
## Revoke one
**AI tools**, find the key, revoke it. It stops working immediately; any tool
using it gets an authentication error on its next call.
## What you can see
For each key: its label, its first characters, when it was created, and when it
was last used. For Claude Desktop connections: the same, without a key.
"Last used" is the quickest way to spot a tool you've forgotten about. If a key
hasn't been used in months, revoke it.
# How Vythos is secured
Source: https://doc.vythos.tech/security/overview
# How Vythos is secured
Your rules are among the more sensitive things an agency owns: what you charge,
what you've committed to, what you've agreed with each client. Here's how that
material is kept.
## Workspaces are isolated in the database
Every row Vythos stores carries the workspace it belongs to, and that isolation
is enforced by the database itself rather than by application code remembering
to filter. The account the application connects with cannot bypass it.
The practical meaning: a bug in a query can't return another workspace's
material, because the database will not serve it.
## Inside your workspace
- **Rules are shared, filtered by access.** Each person has a level for each
category, and a category set to no access is never sent to them — not on
screen, not to their AI tools. See
[Your team and their access](/using-vythos/team-and-access).
- **Memory is private to each person.** Your uploads and your connected
accounts feed your memory only. Nobody else can search it, the workspace
owner included.
- **Connections are personal.** Each person authorises their own Google, Notion
or GitHub account, and Vythos reads with exactly that person's access.
## Connector access is encrypted at rest
The tokens that let Vythos read your Drive or Notion are encrypted before they
are stored, with authenticated encryption, and are decrypted only to make a
request on your behalf. They are never written to logs, never returned by the
API, and never shown in the app.
## Sign-in
- Passwords are hashed with bcrypt. Nobody at Vythos can read yours.
- Repeated failed sign-ins for an address are throttled, and the throttle is
checked before the password, so a refused attempt reveals nothing about
whether an account exists.
- Password reset is by emailed link.
## What reaches a model
Vythos uses large language models for two things: writing an answer in Ask, and
reading values out of a document when you add a rule. A separate model turns the
text of each document into a search index (embeddings) when it's read in, and
each question into the same form when you search.
- The models run on **Microsoft Azure (Azure OpenAI)**, in the EU: requests are
processed only in EU member states.
- What's sent is the material needed for that request — for a question, the
rules and passages relevant to it, your agency's description and client list,
and the last few turns of your own conversation; the text of the document
you're adding; or, for indexing, the passages of a document.
- Microsoft's terms are that prompts and answers are not used to train models,
are not available to OpenAI or any other model provider, and are not available
to other customers. Vythos does not train anything on your material either.
- Azure runs automated abuse monitoring. Content it flags may be kept for human
review, stored in the EU and reviewed only by authorised Microsoft staff in the
European Economic Area.
- The rest of the product — following documents, versioning, permissions,
checking a draft against values — involves no model at all. Draft checks in
particular are deterministic: the same draft and the same rules produce the
same result every time.
## What Vythos stores, and what it doesn't
**Stored:** the text of documents you connect or upload, split into passages
and indexed; your rules and their history; your clients and your agency's
description; your team and their access; each person's Ask conversations,
readable only by them; records of what was handed to which AI tool, so a draft
can be checked against it.
**Not stored:** your files themselves. Vythos reads documents where they live
and keeps the text; it never becomes the place your documents are kept.
## Outside services involved
| Service | What for | What it sees |
|---|---|---|
| Microsoft Azure — Azure OpenAI, EU | Generating answers, reading values from documents, indexing text for search | The text needed for that request; each passage of a document when it's indexed |
| Google, Notion, GitHub | Reading the documents you connect | Only what the account you connected can see, and only what you selected |
| An email provider | Invitations and password-reset links | The address and the message |
## Reporting something
If you think you've found a security problem, email us rather than opening a
public issue, and give us a way to reproduce it. We'll confirm we've received
it and tell you what we're doing about it.
Next: [Your data](/security/your-data).
# Your data
Source: https://doc.vythos.tech/security/your-data
# Your data
## What's held
| | What it is | Where it came from |
|---|---|---|
| **Rules** | The text of each rule's document, its values, and every version | Documents you named |
| **Memory** | Passages from documents you connected or uploaded, indexed for search | Your sources |
| **Clients** | Names you added | You |
| **Your agency's description** | What you do and who for, as entered in Settings | You |
| **Ask conversations** | Each person's questions and answers, readable only by that person | Each person, as they ask |
| **People and access** | Your team, their roles, their category access | You |
| **Connections** | Encrypted tokens for the accounts you connected | Your authorisation |
| **Handover records** | Which rules and versions went to which AI tool, and what it reported back | Your tools |
Your original files are not stored. Vythos reads them where they live.
## Changing what's held
| To… | Do this |
|---|---|
| Correct a rule | Edit its document. The rule follows within about ten minutes |
| Stop a rule applying | Retire it. Its history is kept |
| Replace a document's text in memory | Upload the file again, or re-sync its source. The old text is replaced, not added to |
| Stop a source feeding memory | Disconnect it in Sources |
| Remove Notion's material | Disconnect Notion — it clears what it put in your memory |
| Remove a conversation | Delete it from the list beside Ask. Only you can see yours, so only you can delete them |
| Change your agency's description | Settings (owner) |
| Remove everything | Delete the workspace in Settings |
::: warning Disconnecting is not deleting, except for Notion
Notion clears its memory on disconnect. Google Drive, GitHub and Gmail remove
access but leave what they already read. If you need a particular source's
memory cleared without deleting the workspace, ask us — it's a request we
handle by hand today.
:::
## Deleting the workspace
**Settings → Danger zone → Delete workspace.** It asks you to confirm, and then
everything goes: rules and their history, memory, conversations, clients,
members and their access, connections, and every record of what was handed to
an AI tool.
The deletion is derived from the shape of the database rather than a list
someone maintains, so nothing is left stranded. It cannot be undone, and we
cannot recover a deleted workspace for you.
What it doesn't touch: your documents in Drive, Notion or on your computer.
They were never ours.
## When someone leaves
There's no way to remove a person from the workspace in the app today. To stop
anything shared reaching them, set every kind of rule to *No access* on the
Members page — it takes effect on their next question — and ask us to close
their account. Their own memory and conversations stay theirs, and unreadable
by anyone else, until then.
One consequence worth planning for: **rules are read with the access of
whoever added them**, so rules added from a departing colleague's Drive stop
following their documents once their Drive access ends. Add those documents
again from an account that's staying. See
[When a file can't be read](/using-vythos/unreadable-files).
## Data protection requests
If someone asks you to produce or delete personal data held in your workspace —
a subject access request — most of it is answerable from the product: memory is
per person, and what a person uploaded or connected can be removed with them.
Ask conversations are per person too: the person can read and delete their own,
and nobody else can — the owner included — so a request that covers someone
else's conversations is one to bring to us.
For anything you can't do from the app, ask us. Vythos records the processing
it does on your behalf, and we'll help you answer.
## Where the data lives
In our managed infrastructure, with models run on Microsoft Azure (Azure OpenAI)
in the EU — requests to the models are processed only in EU member states. If
your clients require a specific region or a data processing agreement, talk to
us before you sign anything that commits you.
## Keeping your own copy
Your rules are documents you already own, in your own Drive, Notion or
computer — which is the point of the model. Vythos holding them is a
convenience, not custody. If Vythos disappeared tomorrow, your rate card would
still be exactly where it is.
# File formats
Source: https://doc.vythos.tech/reference/file-formats
# File formats
Vythos reads text. A file it can't read is never silently dropped — it's
reported with its name and the reason, wherever you meet it: in a sync report,
in the file picker, or when you try to make it a rule.
## Read
| Format | Extensions | Notes |
|---|---|---|
| PDF | `.pdf` | Text-based PDFs. A scan with no text layer has nothing to read |
| Word | `.docx` | Tables included |
| Excel | `.xlsx`, `.xlsm` | Sheets arrive as rows |
| PowerPoint | `.pptx` | Slide text and notes |
| Markdown | `.md`, `.markdown` | |
| Plain text | `.txt` | |
| CSV / TSV | `.csv`, `.tsv` | |
| HTML | `.html`, `.htm` | |
| JSON | `.json` | |
| Rich text | `.rtf` | |
## Google's own formats
Read in full, with their structure intact:
| In Google Drive | What comes through |
|---|---|
| Google Docs | The document, headings and tables kept |
| Google Sheets | Every sheet, as rows |
| Google Slides | Slide text and notes |
Google Forms, Drawings, Sites, Jamboards and Apps Script files are refused by
name: there's no useful text to export.
## Not read
Refused by name, with the reason, rather than downloaded and failed:
| Group | Formats |
|---|---|
| **Legacy Office** | `.doc`, `.xls`, `.ppt` — re-save as `.docx`, `.xlsx` or `.pptx` |
| **Apple iWork** | `.pages`, `.numbers`, `.key` — export as PDF or Office |
| **Images** | `.png`, `.jpg`, `.gif`, `.webp`, `.heic`, `.tif`, `.svg` |
| **Design files** | `.psd`, `.ai`, `.indd`, `.sketch`, `.fig` |
| **Video** | `.mp4`, `.mov`, `.avi`, `.mkv`, `.webm` |
| **Audio** | `.mp3`, `.wav`, `.m4a`, `.aac` |
| **Archives** | `.zip`, `.rar`, `.7z` |
Reading rules out of an image — a brand guideline exported as PNG, a scanned
signed contract — isn't supported. If the rule is in a picture, put the words
in a document.
## Practical advice for rule documents
- **PDF is fine**, as long as it was exported rather than scanned. If you can
select the text in a PDF viewer, Vythos can read it.
- **Tables survive** in Word, Excel, Google Docs, Google Sheets and Markdown —
which matters most for rate cards.
- **A spreadsheet is read as rows**, so a rate card as a spreadsheet works.
Give columns clear headings.
- **Check what came through.** The Add rule card has *Read the document*, which
shows exactly what Vythos took. Worth doing once for each kind of document.
## When a file is refused
| Message | What to do |
|---|---|
| *Vythos does not read Google forms / drawings / …* | There's no text to read. Use a Doc |
| A legacy format refusal | Re-save it in the modern format |
| *'…' is empty* | The file has no readable text — usually a scan |
| *That's a folder* | Pick the file inside it |
# These docs, for AI agents
Source: https://doc.vythos.tech/reference/for-ai-agents
# These docs, for AI agents
If you're an assistant reading this on someone's behalf — or a person who'd
rather paste a page into a chat than screenshot it — everything here is
available without the HTML.
## Any page as Markdown
Add `.md` to any URL:
```
https://doc.vythos.tech/concepts/values → the page
https://doc.vythos.tech/concepts/values.md → its Markdown
```
Every page has one. It's the file the page was written from, front matter
included, so a title and a one-line description come with it.
Each page also carries a **Copy page** button, which copies exactly that
Markdown — handy for pasting a page into a conversation with a tool that can't
fetch a URL.
## The whole site, two ways
| File | What it is | When to use it |
|---|---|---|
| [`/llms.txt`](https://doc.vythos.tech/llms.txt) | Every page, with a one-line description, in reading order | Find the right page in one request instead of crawling |
| [`/llms-full.txt`](https://doc.vythos.tech/llms-full.txt) | The entire documentation in one file, about 20,000 words | Read everything once and answer from it |
Both are generated from the same source as the site, so they can't drift from
what a person sees.
## Setting Vythos up for someone
If you're helping someone get started, the short version:
1. They create a workspace and add their first rule from a document they
already have — [Quickstart](/getting-started/quickstart).
2. They connect where their documents live —
[Google Drive](/sources/google-drive) or [Notion](/sources/notion) — so
rules follow the files.
3. You connect to their workspace over MCP —
[Connect a tool](/ai-tools/connect) — using a key they create.
The thing to understand before advising them:
[a rule is a document a person names](/concepts/rules-and-documents), and
nothing becomes a rule any other way. If you're tempted to tell them to paste
their rate card into a box, there isn't one, and that's deliberate.
## Working against a live workspace
Documentation is the wrong tool for a customer's actual rules. Their workspace
serves those over MCP, filtered by the access of whoever's key you're using:
- `get_context` — the rules that apply to a task, client rules first
- `check_draft` — a draft against the rules it was given
- `search_memory` — their own documents and history
- `log_outcome` — what you followed, and where you departed
Each is described in [The four tools](/ai-tools/tools), and what a pack
contains is in [What your agent receives](/ai-tools/what-agents-receive).
## Crawling
`robots.txt` allows everything and points at `/sitemap.xml`. There's no rate
limit worth mentioning; the whole site is 36 pages.
# Limits and timings
Source: https://doc.vythos.tech/reference/limits
# Limits and timings
## How often things happen
| What | When |
|---|---|
| A rule's document is checked for changes | About every **10 minutes** |
| Google Drive memory sync | About every **30 minutes**, slowing while nothing changes |
| Notion memory sync | About every **15 minutes**, same |
| Website, GitHub, Gmail | On demand |
| An uploaded rule's update | Immediately, when you upload the file again |
| An access change | Takes effect on the next question or context request |
| A retirement | Immediately |
A source that has gone quiet is checked less often, and returns to its normal
cadence as soon as something changes. You can always sync by hand from the
Sources page.
## Sizes
| What | Limit |
|---|---|
| A document uploaded during setup | 20 MB |
| Website crawl | 30 pages by default, 100 maximum |
| Drive folder listing when picking a file | 1,000 items, and it tells you when a listing was cut short — search by name instead |
| Context handed to an AI tool | About 12,000 tokens by default; a tool can ask for more or narrow the categories |
| Passages returned by a memory search | 8 by default, 50 at most |
| Sources behind an Ask answer | 5 by default, 20 at most |
| Earlier turns Ask reads to understand a follow-up | The last 6 messages — three questions and their answers |
| Clients Ask names | Up to 60 active and 60 dormant by name; the count is always exact. An AI tool receives the full list |
## Durations
| What | How long |
|---|---|
| An invitation | **7 days**, then it needs sending again |
| A key | Until you revoke it |
| A rule's history | Kept indefinitely — nothing is deleted when a rule changes or retires |
| Memory | Kept until you remove it or delete the workspace |
| An Ask conversation | Kept until you delete it or the workspace is deleted |
## Counts
| What | Limit |
|---|---|
| People in a workspace | One on Free and Solo; everyone on Team. See [Plans and credits](/using-vythos/plans-and-credits) |
| Rules | No limit |
| Clients | One live on Free (the rest are paused, not deleted); no limit on Solo and Team |
| Categories | Fixed at seven. See [Categories](/concepts/categories) |
| Keys per person | No limit, though one per tool is the sensible habit |
| Ask questions a month | 30 on Free, 300 on Solo, 1,500 shared on Team — one credit each. AI tools use none |
## Things worth knowing
- **One document makes one rule.** Filing the same document under a second
category moves it rather than duplicating it.
- **A rule with no readable document keeps working.** It stops following, and
says so.
- **Two rules stating the same value at the same scope** are a disagreement
Vythos won't resolve. Neither value is handed to a tool as authoritative;
retire one.
# Troubleshooting
Source: https://doc.vythos.tech/reference/troubleshooting
# Troubleshooting
## Rules
**I edited the document and the rule hasn't changed.**
Give it ten minutes — that's the checking cycle. After that: did you edit the
*same file*, or save a new one? A new file is a new document. Add it and tick
*replaces*. If the rule shows an orange note, Vythos can't read the file at
all — see [When a file can't be read](/using-vythos/unreadable-files).
**I uploaded the new version and nothing happened.**
Uploads update a rule when the file has the **same name** and is uploaded by
the **same person** who added the rule. A different name is a different
document.
**The rule's text is missing the part that matters.**
Open the rule and read what Vythos took from the document. Common causes: the
content is in an image; the PDF is a scan; the page has sub-pages in Notion
that are separate documents. See [File formats](/reference/file-formats).
**The rule has the wrong name.**
Names come from the document's first heading, or the file name. Give the
document a heading, or rename the file; the rule follows at the next check.
**Two rules say different things.**
That's a disagreement in your Playbook, and Vythos won't pick a winner — it
tells your tools the rules conflict. Retire the one that no longer applies.
**I can't add a rule.**
Only the workspace owner adds and retires rules today — the Playbook page is
theirs. Ask them to add the document, or to change the access you were given
so you're ready for when teammates can.
## Ask
**It says it doesn't have something I know is in there.**
Check the material is in memory — a file you never uploaded or synced isn't.
And check the asker's access: a category they can't see is never used in their
answer.
**It gave me an old figure.**
Look at which rule it cited and open the document. If the document is current
and the rule is behind, the rule updates within ten minutes. If the answer came
from a document rather than a rule, that document really does say that — worth
fixing at the source.
**It won't do the arithmetic.**
By design. Figures are quoted in the unit the rule states them in, never
combined into new ones, because a derived number appears in no version of your
Playbook. Ask gives you the figures and the rule.
**A follow-up was taken to mean something else.**
Ask reads a follow-up in light of the last few turns. If it guessed wrong, say
the subject — *"Greenleaf's logo"* rather than *"their logo"* — or start a
**New chat** for something unrelated.
**An answer I was waiting for isn't in the conversation.**
If you reloaded or left while it was being written, it's still finished and
kept — give it a few seconds and open the conversation again.
**Can I see what my team has asked?**
No, by design. Each person's conversations are theirs alone, like their memory
— the owner included. People ask more freely when their questions aren't read.
## Sources
**A file didn't sync.**
Check the format list. Legacy Office files, Apple iWork files, images and
scanned PDFs can't be read; they're reported with the reason rather than
skipped silently.
**Folder sync won't open a picker.**
Selecting a folder from your computer needs Chrome or Edge. Other browsers work
for everything else.
**I disconnected a source and the content is still searchable.**
Notion clears its memory on disconnect; Drive, GitHub and Gmail don't. Ask us
if you need a source's memory cleared on its own — deleting the workspace
removes everything.
## AI tools
**My tool connects but gets nothing useful.**
Check the access of whoever owns the key — a key carries that person's access.
Then check the tool is actually calling Vythos; some need to be told
explicitly ("get the rules from Vythos first").
**Every call is rejected.**
The key is wrong, revoked, or the header is missing `Bearer `. Create a new key
and paste it fresh.
**Claude Code connects and then drops.**
Use `--transport http`, not `sse`. The address ends in `/sse`, but the server
speaks Streamable HTTP.
**A draft check came back clean but the draft breaks a rule.**
Read the `unchecked` list in the result. Only banned words and payment terms
are checked today; a clean result means nothing was found among those. See
[Values](/concepts/values).
## Team
**My colleague never got their invitation.**
Invitations expire after 7 days — send another. Check spam. If email still
isn't arriving, tell us; we can get you the invitation link directly.
**A freelancer can see something they shouldn't.**
Check their access per category on the Members page, and their assigned
clients. Both take effect on their next question — there's nothing to re-issue.
**How do I remove someone?**
There's no way to remove a person in the app today. Set every kind of rule to
*No access* on their Members entry — it takes effect on their next question —
and ask us to close their account. See
[Your team and their access](/using-vythos/team-and-access).
**Someone left and rules stopped updating.**
Rules are read with the access of whoever added them. Add those documents again
from an account that's staying.
## Still stuck
Tell us what you did, what you expected, and what happened — with the rule's
name if it's about a rule. If it's about an AI tool, the tool's name and what
it called helps more than anything else.
# Glossary
Source: https://doc.vythos.tech/reference/glossary
# Glossary
**Ask** — the page inside Vythos where you ask questions in plain language.
Answers come from your rules and your own memory, never from the wider world.
[More](/using-vythos/ask)
**Category** — one of seven kinds of rule: Terms & commitments, Pricing &
rates, How we work, Brand & voice, Who decides, Strategy, Past decisions. A
rule has exactly one. Access is granted per category.
[More](/concepts/categories)
**Client** — a name you added, that rules can be attached to. A client's rule
overrides your house default for that client's work. [More](/concepts/clients)
**Confirmed value** — a value a person has checked and vouched for. A draft
contradicting one is reported as breaking the rule, rather than as worth a
check. [More](/concepts/values)
**Conversation** — a run of questions and answers in Ask, kept so a reload loses
nothing and a follow-up is understood. Readable only by the person who asked.
**Context pack** — what an AI tool receives when it asks for the rules that
apply to a task: the relevant rules in precedence order, their values, and an
account of anything left out.
[More](/ai-tools/what-agents-receive)
**Key** — the credential a tool connects with. It carries the access of the
person who created it. [More](/ai-tools/keys)
**MCP** — the Model Context Protocol, the standard AI tools use to connect to
outside systems. How Claude, Cursor and others reach your Playbook.
[More](/ai-tools/overview)
**Memory** — the searchable text of everything you've connected or uploaded.
Private to each person, and never governing. [More](/concepts/memory)
**Owner** — whoever created the workspace. Today, the only person who adds and
retires rules.
**Playbook** — the set of documents your agency's work must respect. The rules,
organised by category and scope. [More](/concepts/playbook)
**Precedence** — the order rules are ranked in. Scope first (a client's rules
beat house rules), then category. Tools are told the order explicitly.
**Rule** — a document someone named as governing. Not typed-in text: a Drive
file, a Notion page or an upload that Vythos follows.
[More](/concepts/rules-and-documents)
**Retire** — to stand a rule down. It stops reaching people and tools
immediately; its text and history are kept.
[More](/using-vythos/retire-a-rule)
**Replaces** — the tick that says a new document supersedes an existing rule.
Without it, two documents covering the same ground both stay in force.
[More](/concepts/versions)
**Scope** — who a rule governs: *every client*, or one named client. Separate
from permissions, which decide who may *see* it. [More](/concepts/clients)
**Source** — a connected account or upload that feeds memory: Google Drive,
Notion, uploads, your website, GitHub, Gmail. [More](/sources/overview)
**Value** — a figure or list read out of a rule: a day rate, payment terms in
days, words never to use. Sent to tools labelled with what it is, so nothing
has to be inferred from prose. [More](/concepts/values)
**Version** — a rule's number, starting at 1 and rising each time its document
changes wording. Old versions are kept, and a draft is checked against the
version its author was given. [More](/concepts/versions)
**Workspace** — your agency in Vythos: one Playbook, your clients, your people.
# index.md
Source: https://doc.vythos.tech/
## Where to start
| If you want to… | Read |
|---|---|
| Understand what this is and whether it fits your agency | [What Vythos is](/getting-started/what-is-vythos) |
| Get a workspace running with your first rules | [Quickstart](/getting-started/quickstart) |
| Know which of your documents to add first | [Which documents to add first](/getting-started/which-documents-first) |
| Put your rules inside Claude, Cursor or your own agent | [Connect a tool](/ai-tools/connect) |
| Give your team access without handing over the rate card | [Your team and their access](/using-vythos/team-and-access) |
| Know exactly what is stored and where | [Your data](/security/your-data) |
| Read these docs as an AI agent, in Markdown | [These docs, for AI agents](/reference/for-ai-agents) |
## How the pieces fit
A document becomes a **rule** only when a person names it. Everything you connect also lands in **memory**, which is searched but never governs. Both reach the place you work — with rules taking precedence.