# Scytian documentation, full text Source: https://scytian.com/docs Pages: 26 --- # What Scytian is Section: Start here Address: https://scytian.com/docs/what-scytian-is Updated: 2026-09-14 Scytian is a web application in which a company has AI agents, and those agents do its administrative work. An agent has a name, a description of the role it stands in for, memory, written rules and access to the systems your company already uses. Work reaches an agent in two ways. A **job** runs on its own when something happens: an invoice arrives, it is the first of the month, another system sends an event, somebody submits a form. Or you **ask in the chat**, in your own words, for something that happens once. ## What it replaces The work between systems and people that nobody enjoys and everybody does by hand. Reading documents and writing them into your accounting. Producing documents and sending them. Keeping two systems in agreement. Assembling the same report every Monday. Answering "how much did we spend on this" from your own records. ## What it is not It is not a canvas you wire by hand. You describe the job, the agent writes the plan, you approve it. It is not a chatbot. A chatbot answers. An agent does the work and writes down what it did. It is not a replacement for the person responsible. The judgement that has to stay human is named in the plan and keeps coming to a person. ## Where your data is In your systems, where it already is. The platform reads and writes through the interfaces those systems offer, and keeps the process: the approved plans, your rules, your encrypted keys and the log of every run. See [Where your data lives](/docs/where-your-data-lives). --- # How it works, in one page Section: Start here Address: https://scytian.com/docs/how-it-works Updated: 2026-09-14 Every process on the platform goes through the same six steps. They are the same for an invoice, a report and a form. ## 1. You say what should happen In your own words, in the chat or on a call. What arrives, where it should end up, and what should stop the job. See [Talking to an agent](/docs/talking-to-an-agent). ## 2. The connections get sorted What has to be reachable and how. A key, a sign-in, a shared folder, a mailbox. You hold the keys; the agent calls a connection by name and never receives the value. See [Connections and keys](/docs/connections-and-keys). ## 3. You approve the plan The agent writes the job as a plan in plain language: the steps, the fields it will write, the decisions it may make alone, and what will never happen. Nothing is built before you approve it. See [Jobs and plans](/docs/jobs-and-plans). ## 4. It is measured on your own cases Before the job can write anything into your systems, it is scored against answers you confirmed on a batch of your real files. Below the agreed number the switch stays off. See [Measured before it goes live](/docs/measured-before-live). ## 5. It runs On a schedule, on a webhook, or when a form is sent. Most runs are a script and cost nothing. The agent steps in for the judgement call and when something outside your control changes. See [Script first, agent when needed](/docs/script-and-agent). ## 6. You see every run What started it, what each step did, what it cost, and why it stopped if it stopped. Questions reach you as one notification. See [Timeline and runs](/docs/timeline-and-runs) and the [ROI report](/docs/roi-report). --- # Glossary Section: Start here Address: https://scytian.com/docs/glossary Updated: 2026-09-14 | Word | What it means | | --- | --- | | **Desk** | A part of the company an agent covers: finance, back office, sales, operations, management, HR, marketing. | | **Agent** | The role that does the work on a desk. It has memory, rules and access. Never a person with a made up name. | | **Job** | One process that runs: its trigger, its plan, its tools and its limits. | | **Run** | One execution of a job, with a start, steps, a cost and a result. | | **Plan** | The job written in plain language, approved by a person before anything is built. | | **Trigger** | What starts a run: a schedule, a webhook, a form, or a manual test. | | **Script** | The deterministic part of a job. Same input, same result, no model cost. | | **Fallback** | The agent finishing a run when the script cannot, then repairing the script. | | **Handoff** | The script deliberately passing one decision to the agent, with the context prepared. | | **Connection** | An access to one of your systems: an API key, a sign-in, a service account or an MCP server. | | **Norm** | A rule of the platform, written by Scytian, the same for every customer. | | **Rule** | Your rule, for your desk or your job, written down and readable. | | **Skill** | A written procedure an agent follows for a task that repeats. | | **Memory** | What an agent has learned and had confirmed, in text you can read and change. | | **Contract** | The agreement about what a job must produce: the fields and what counts as correct. | | **Truth** | The correct answers you confirmed on your own files, used to score the job. | | **Gate** | The number a job has to reach before it can be switched on. | | **Timeline** | The record of every run and every step, with costs and decisions. | | **Inbox** | Where a question from an agent waits for a person. | | **Model** | The language model a step uses when it needs judgement. Anthropic's Claude models, under business terms. | | **Runner** | The isolated container in which your agents run. One per customer. | | **Control room** | The part of the platform that holds plans, the timeline and encrypted keys. | --- # The app and notifications Section: Start here Address: https://scytian.com/docs/app-and-notifications Updated: 2026-09-14 Scytian is a web application. There is nothing to download from a store. It opens at one address, on a computer, a tablet or a phone, with the same account and the same data everywhere. ## Putting it on a phone or a desktop Open the address in the browser and add it to the home screen. From then on it opens full screen without browser bars, keeps you signed in, and can send notifications. On a computer it installs the same way and keeps its own window. ## Turning notifications on Notifications are off until someone turns them on, once per device, in the settings. The browser asks for permission and you confirm it. Each device is remembered separately. A phone and a laptop can both be on, or only the phone, and turning one off leaves the other running. On an iPhone, Apple delivers notifications only to a web app that has been added to the home screen. Left in a browser tab, they never arrive. ## What actually sends one Two things, and nothing else. **An agent needs an answer.** A step is irreversible and the plan says a named person decides it. The notification carries the question. See [Three ways out](/docs/three-ways-out). **A report is ready.** The Monday numbers, a check you asked for, a finished measurement. See [Reports and questions](/docs/reports-and-questions). There is no notification per run, no alert when something went fine and no daily digest. A process that works is silent. That is the point of it. ## What happens when you tap one The notification opens the exact place, the conversation or the waiting item, not the front page of the app. A newer notification about the same thing replaces the older one instead of stacking, so a busy morning does not leave a pile to clear. ## The inbox Questions and reports collect in one list, and it is the only place where something waits for you. A question carries the buttons that decide it and the facts the decision needs, so it can be answered without opening anything else. A report can be turned into a conversation with the agent with one tap, which is how you ask why a number looks the way it does. What is waiting is never buried in a chat. The platform puts it there, not the agent. ## Offline and updates The app itself is cached so it opens instantly, but everything about your work comes from the network each time. Runs, reports and conversations are not stored on the phone, so a lost phone carries no company data. Updates arrive on their own when the app opens. There is nothing to reinstall and no version to keep an eye on. --- # Agents and desks Section: Agents Address: https://scytian.com/docs/agents-and-desks Updated: 2026-09-14 An agent is a **role**, not a person with a made up name. In your workspace the agents are called Finance, Back office, Operations, and so on, because that is how a company divides work, and because a role can be judged on the handful of calls it has to make right every day. ## What an agent is made of **A description of the role.** What this desk is responsible for, in whose company, with what tone. Written once, readable and editable. **Memory.** What it has learned about your company and had confirmed. See [Memory](/docs/memory). **Norms and rules.** The platform norms that apply to every agent, and your rules for this desk. See [Norms and rules](/docs/norms-and-rules). **Connections.** The systems this desk may reach, each with its own access. See [Connections and keys](/docs/connections-and-keys). **Jobs.** The processes this desk runs. See [Jobs and plans](/docs/jobs-and-plans). ## Tools Each job carries the set of tools it is allowed to use. A job that reads a mailbox and writes into accounting does not get a browser or a shell. The administrator sets a ceiling for the whole agent, and the agent cannot give itself back a tool that was taken away. It can only ask, and a person decides. ## How many desks Start with one. Each desk is measured on its own jobs and has its own ROI report, so adding a second is a decision you make on numbers, not on a feeling. ## What an agent never does It never invents an identity. A supplier, a customer or a project it cannot find is a stop, not a new record. It never widens its own reach. Not a system, not a permission, not a library. It never decides about a person. The facts are prepared; the decision goes to a manager. --- # Memory Section: Agents Address: https://scytian.com/docs/memory Updated: 2026-09-14 An agent keeps memory so you do not repeat yourself. It is written text, not a hidden model state. You can read all of it and change all of it. ## What goes into memory Facts about your company that are true beyond one conversation. Which supplier belongs to which project. That fuel invoices are booked to Fleet. That one customer sends invoices as photos. That the month is closed on the fourth working day. What does not go into memory: anything from a single run that has no meaning tomorrow, and anything a person has not confirmed. ## How it is written Each memory is one short entry with a heading, the fact itself, and the keys under which it should be found again. Before an agent starts a task it compares what you wrote with those keys and reads what matches, so the right handful of entries is in front of it instead of everything at once. ## Learning happens through a gate An agent does not quietly decide that something is now a rule. When it notices a pattern, it proposes it, and the entry becomes permanent when a person confirms it. That is the difference between an assistant that drifts and one you can hand a process to. In the chat this looks like one sentence: "Written down. From now on every invoice from a fuel supplier is booked to Fleet." Before that sentence, nothing changed. ## What it cannot repeat An agent reads what it was given access to and nothing else. Mailboxes, folders and records outside its connections are not part of its memory, and what it never read it cannot repeat. ## Where you see it In the agent settings: the rules card, the memory entries, and the generated index of what the agent knows. Changing a line there changes what the agent does on the next run. --- # Norms and rules Section: Agents Address: https://scytian.com/docs/norms-and-rules Updated: 2026-09-14 Three kinds of written instruction sit behind every run, and they are not equal. ## Platform norms Written by Scytian, the same for every customer, and not editable from the outside. They cover how work is done safely rather than what your business does. Examples of what a norm settles: - An agent never invents an identity. A record it cannot find is a stop. - Uncertainty is resolved by the plan, not by the agent at runtime. See [Three ways out](/docs/three-ways-out). - Nothing is claimed as done that was not verified against the system it was written into. - Secrets never appear in a chat, a log or a prompt. - A job is measured before it is switched on. Norms exist because the same mistakes repeat across companies. When we find one, we close it for everybody, not for one customer. ## Your rules Your rules describe your business: limits, who approves what, how a document should read, which account something is booked to. They live on the desk or on the job, they are visible in the plan and in the agent settings, and you change them in plain words. A rule can narrow what an agent does. It cannot loosen a platform norm. You can say "anything over 10 000 asks me first". You cannot say "create the supplier if you cannot find it". ## Skills A skill is a written procedure for a task that repeats, so the agent does it the same way every time. Three kinds exist: a procedure for the agent, a triage runbook for when a script fails, and a decision list for a handoff. Skills are part of the agent, not of one conversation. ## Precedence Platform norms first, your rules second, the agent's judgement last and only where the plan leaves it room. --- # Talking to an agent Section: Agents Address: https://scytian.com/docs/talking-to-an-agent Updated: 2026-09-14 Most of what an agent does runs on its own. The rest is a conversation, in the same window where the job was set up. ## What you can ask for **A one-off job.** Something that happens once and does not deserve an automation. "Take these forty files and put the totals in a table." **A new automation.** "From now on, when a delivery note arrives, match it to the order." The agent answers with a plan and nothing is built before you approve it. **A question about your data.** "Who has not paid us?" The answer comes from your systems with the source under it. See [Reports and questions](/docs/reports-and-questions). **A change to a rule.** "Fuel invoices go to Fleet from now on." It is written down for good, not for this chat. See [Memory](/docs/memory). ## What comes back Plain language, and where it helps, a block you can act on: a question with buttons, a table, a chart, a card to approve. A card that has to be approved is delivered by the platform, so it cannot be faked inside a conversation. You can also send files. A document, a spreadsheet, a template or a script. ## How a run ends Every answer ends with the same three lines: what is done, what the next step is, and what waits for you. If the agent says a job is finished, it has to show the check it ran against the system it wrote into. A claim without that check is not accepted by the platform. ## When it cannot do something It says so and waits. It does not quietly give itself a system, a permission or a library it was not granted, and it does not guess an identity to keep a run going. --- # Three ways out, do, ask, stop Section: Agents Address: https://scytian.com/docs/three-ways-out Updated: 2026-09-14 Every step of every job has exactly three ways out, and which one applies is written in the plan before the job is built. ## Do The step is reversible and the plan says the agent may act. It acts and writes down what it did. You read about it in the run report, not in the moment. ## Ask The step is irreversible: money moves, a document leaves the company, a record cannot be taken back. The agent stops and asks a **named person**, with a time limit written in the plan. The question arrives as a notification on the phone and as an item in the inbox. One tap answers it and the run continues. ## Stop Everything else. The agent does nothing, ends the run and says why. A stop is a normal outcome, not a failure, and it is the default for anything the plan did not anticipate. ## Why it is decided up front An agent deciding at runtime how brave to be is the thing that makes automation impossible to trust. Here the decision is made once, by a person, on a plan that can be read. The agent cannot decide to be braver on a Tuesday. ## What you see In the plan: which steps may act alone, which ask, and who is asked. In the timeline: which way out each step took. In the inbox: what is waiting for you right now. --- # Jobs and plans Section: Automations Address: https://scytian.com/docs/jobs-and-plans Updated: 2026-09-14 A **job** is one process that runs: its trigger, its plan, the tools it may use, its limits and its ROI fields. ## The plan Before a line of code exists, the job is written as a plan in plain language. It contains: - **The steps**, each with what it reads and what it writes. - **The fields**, as a table: what is written where, and where each value comes from. - **The decisions**, with the way out for each one. See [Three ways out](/docs/three-ways-out). - **The guarantees**: what will never happen, whatever the input. - **The open questions**, where the plan needs an answer from you. You approve it, or you ask for changes. Asking for changes rewrites the plan; it does not patch it. ## Why the plan and not the code You cannot review code you did not write, and a screenshot of a canvas does not tell you what happens when a field is missing. A plan in your own vocabulary is the thing you can actually hold somebody to, and it is what the platform measures the job against later. ## Taking over an existing flow If the process runs today in another tool, the existing flow is read and documented as it really runs before anything is rebuilt. When the new job goes live, the old flow is listed and switched off deliberately, not left running in the background. The platform asks for that list before a job that replaces something is switched on for the first time. ## Changing a job later Every change goes the same way: plan, approval, measurement. A job that is already live keeps running while the change is prepared. --- # Script first, agent when needed Section: Automations Address: https://scytian.com/docs/script-and-agent Updated: 2026-09-14 A job is not "an AI that does everything". Most of what a process does is mechanical, and mechanical work belongs in a script. ## By default, a script does the work Same input, same result, in under a second, with no model cost. That covers the large majority of runs. It is also what makes a thousand documents cost roughly the same as ten. ## On purpose, the script hands over one decision Some steps cannot be a rule. Is this the same supplier under a different name? Is this line a discount or a fee? The script does the mechanical part and hands that one decision to the agent with the context already prepared. This is a **handoff**, and it is written in the plan. ## When something breaks, the agent finishes the run A supplier renames a field, a portal changes a form, an export gains a column. The script fails, the agent takes over, finishes today's work another way, and then rewrites the script so tomorrow is back on the cheap path. You get one line about it in the report instead of a morning lost. ## What it costs Every run writes down what it cost. A script run costs nothing in model terms. An agent run costs cents. A conversation costs both. All of it appears per job in the [ROI report](/docs/roi-report), which is also where you see how often the agent had to step in. --- # Triggers Section: Automations Address: https://scytian.com/docs/triggers Updated: 2026-09-14 What starts a run is decided in the plan, not left to chance. Four kinds of trigger exist, and more than one can be switched on for the same job. ## A schedule Every fifteen minutes, at six in the morning, on the first working day of the month. Schedules run in your company's time zone, and each person can see the timeline in their own. ## A webhook Another system sends an event and the job runs. Your shop, your CRM, a portal, another automation tool. See [Webhooks](/docs/webhooks). ## A form Somebody presses Send and the job runs, with what they filled in as the input. See [Forms](/docs/forms). ## A manual run You start a run yourself, on a job that is still switched off, with a test payload. That is how a job is tried before it is live, and it is the only way to run something that is not enabled yet. ## What arrives with the run Whatever the trigger carried: the event, the file, the form answers. The plan says which fields are required, and what happens when one is missing. A job that is switched off does not silently swallow a request. The caller is told the truth. --- # Webhooks Section: Automations Address: https://scytian.com/docs/webhooks Updated: 2026-09-14 A webhook is an address plus a token. Another system posts to it and a run starts. ## Access Each job has its own address and its own token, and the token can be rotated without touching the job. A **header secret** can be required on top, so a leaked address alone is not enough. ## Fields The plan says which fields the job needs. Two modes exist. **Tolerant** accepts what arrives and warns about what is missing. **Strict** rejects a request that does not match the agreed shape, with a message that names the field. Strict is the right choice when the caller is a system you control. ## What the caller gets back **An acknowledgement**, immediately, when the calling system only needs to know the event was taken. **The result**, when the calling system waits for it. That includes files: a generated document comes back in the same response. A job can also set its own status code from the script, so a caller learns that its input was wrong rather than receiving a cheerful reply with nothing in it. ## Order and bursts **Parallel** runs requests as they arrive. **Sequential** puts them in a durable queue and runs them one after another. The queue survives a restart of the platform and nothing is dropped: a burst waits rather than failing. Which mode a job uses is part of its plan, and changing it is done while the job is quiet. ## Limits Sixty requests per minute per token, and a payload of up to 256 kilobytes. Above that the caller is told, not ignored. See [Limits and queues](/docs/limits). --- # Forms Section: Automations Address: https://scytian.com/docs/forms Updated: 2026-09-14 A form on this platform is not an inbox. Send is where the work starts. ## Four places a form lives **On a phone in the field.** Opened from a link that already carries the job, so the site, the customer and the contract are filled in before anyone types. Short steps, a summary at the end, a signature with a finger. **On your website.** A link or an embed, for an order, a claim or a request. **Inside a record.** A button on the deal, the order or the employee you are looking at, with everything that record knows already in the form. **In the chat.** A few questions the agent asks in the conversation when it needs them. ## What it checks Any form tool can insist that a number is a number. This one checks the fact against your records: that the job number exists and is still open, that the parts were booked out to this job, that the contract requires photos. It says so while the person who knows the answer is still standing there. Required answers are enforced on the server, not only in the browser, so a consent box cannot be skipped by sending the form another way. ## What happens after Send The submission starts a run like any other trigger: a document is produced, a record is written, a question reaches you, a line appears in the timeline. When a job is set to run one at a time, submissions queue and keep their order instead of overwriting each other. --- # Documents Section: Automations Address: https://scytian.com/docs/documents Updated: 2026-09-14 You send us the file you use today. It stays the file we use. Nobody rebuilds your document in an editor of ours, because from that moment the file on your disk and the one that goes out are two different things. ## How a template works You mark the places where values go, or we mark them with you once. Everything else stays yours: the letterhead, the wording, the footer. Move a paragraph or change the logo and nothing breaks, as long as the marks stay. ## What fills the places Most of them are filled by plain code from the system where the value already lives, in under a second and at no model cost. The agent only fills the places where a rule would have to guess, such as a one line remark about something unusual that month. The plan says which is which. ## Formats Word, Excel, PDF and plain exports. A spreadsheet stays a spreadsheet: formulas still calculate, which is usually why somebody asked for Excel and not a PDF. An official form that has to look exactly as it has for years is filled, not redrawn. ## Signatures Where a person signs on the spot, the signature is captured and travels with the document. Where the law needs a qualified signature, the document goes through a signing service. ## What it never does It never invents a number to fill a gap. A missing value stops the document and names the field and the record it belongs to. It never redesigns your template. --- # Extracting data Section: Automations Address: https://scytian.com/docs/extracting-data Updated: 2026-09-14 Getting values out of a file is the cheap part. The value is in what happens when they do not add up. ## What can go in PDF, whether it carries real text or is a picture of a document. Word and Excel with the header on row four. CSV in somebody else's encoding. XML and JSON. A photo taken at an angle in a car. Structured e-invoices, which are the easy case, are one more shape arriving. However the files already move: a mailbox, a folder, a scanner, a portal, an API. ## Every value carries where it came from Each field says whether it was read from the document, looked up in one of your systems, calculated, or left for a person. A value that was looked up names the key it was matched on. That is what makes a wrong number findable a year later. ## Checks Which checks run is agreed in the plan before the job goes live. They compare against your data, not against the document itself: - **The arithmetic.** Items against the total, net and tax against the sum, with a tolerance you set. - **The identity.** Matched by registration number to a record you already have, never by name. - **The expectation.** An order it came against, and no earlier copy of the same document. ## Nothing is half written When a check fails the file is held with the reason next to it, and nothing is written, not even the fields that were fine. A partially written record is worse than none. ## Measured first A job that writes into your systems is scored on a batch of your own files before it can be switched on. See [Measured before it goes live](/docs/measured-before-live). --- # Reports and questions Section: Automations Address: https://scytian.com/docs/reports-and-questions Updated: 2026-09-14 Two things that look different and run on the same mechanism. ## A report that arrives You say what you want to know and how often. From then on the agent reads your systems, counts it the way your company agreed, and sends it: a notification on Monday morning, a mail, a file. Nobody assembles it and nobody forgets it. A threshold can be attached to any number. Below the line you hear nothing. When it is crossed, one message arrives the same day with the rows behind it. ## A question you ask once Some questions come up because of something that just happened, and building a report for them would take longer than the answer is worth. You ask in plain words and the answer comes back with what it was counted from: which systems, how many rows, how fresh. ## Words have one meaning Two people bring two figures to a meeting because they mean different things by the same word. The definitions are written down once, you approve them, and every report and every answer after that uses them. Revenue means one thing, everywhere. ## The shape follows the answer A trend gets a chart, a comparison gets a table, a single fact gets a sentence. Numbers open into the rows they came from. ## What it will not answer It does not fill a gap with a guess. If half the records have no region, the answer says so and says how many. It is not a forecast. It tells you what happened and what it looks like it is doing. --- # Measured before it goes live Section: Quality Address: https://scytian.com/docs/measured-before-live Updated: 2026-09-14 Anyone can demo an agent on a good example. The question is what it does on fifty of yours, including the ugly ones. So that is what happens before anything is written into your systems. ## The contract First, what correct means is written down: which fields the job must produce, and what counts as a match for each one. Dates, amounts and names can be written in several ways that are all correct, so the rules of comparison are part of the agreement. A person approves the contract before a batch is paid for. ## The truth You confirm the correct answer on a batch of your own files. Where a value is genuinely not on the document, you say so explicitly. That sounds like a detail and it is the difference between a measurement and a guess: an empty field nobody looked at is not evidence of anything. ## The score The platform scores the job against your answers, field by field, and splits the misses into three: a mistake of the program, something nobody could tell from the document, and a difference inside the agreed tolerance. You see the misses with the file next to them. ## The gate A number is agreed for the job. Below it the job does not get switched on. That is a lock in the platform, not a promise on a call. When the number is not reached, the job is tuned and measured again on the same batch. ## The sample A batch of only clean files proves nothing. The platform checks what kind of sample it was given and says so, so a comfortable score cannot be produced by choosing comfortable documents. ## After it is live The job keeps being measured. A shadow copy of what the agent wrote can be compared with what people later corrected, which turns human corrections into the honest weekly answer to "how often was it wrong". --- # Timeline and runs Section: Quality Address: https://scytian.com/docs/timeline-and-runs Updated: 2026-09-14 Every run is on the timeline, and it is written as it happens rather than assembled afterwards. ## What one run shows What started it and with what. Each step as it runs, including the calls to your systems and what they answered. What the agent decided and why. What the run cost. What it produced. A run that handed over to the agent shows both halves: the script part and what the agent did after it. ## Statuses **Running** and **queued** mean exactly that, and a queued run says what it is waiting for. **Done** means the work finished. **Done without action** means the run completed and there was nothing to do, which is different from a failure and is counted separately. **Stopped** is a person or the plan ending the run deliberately. **Error** is a failure, and it reaches the inbox. A run that is killed by a restart does not stay marked as running forever. It is cleaned up and reported. ## Interventions Under each answer the platform lists what the run actually touched: which systems it wrote to, which scripts ran, what was deleted. Deletions are shown separately, because they are the thing you want to see without looking for it. ## Stopping a run A run can be stopped from the interface, including one that is still waiting in a queue. Stopping is recorded as a decision with a name on it. ## Keeping and exporting Runs are kept for as long as you are a customer and can be exported. The record is written once and not edited afterwards. --- # ROI report Section: Quality Address: https://scytian.com/docs/roi-report Updated: 2026-09-14 A token bill tells you what the model cost. It cannot tell you what it was worth, because it does not know what a person costs you or how long the job used to take. So the platform asks for both, once. ## What you set **An hourly rate per desk.** Each desk stands in for a role. Finance work is valued at your accountant's rate, not at an average. **Minutes per job.** When a job is mapped, the work is timed with the person who does it today. That number sits on the job, and every run saves exactly that many minutes. It is a measurement you agreed to, not a projection. ## What the platform adds What each run cost, written by the run itself as it finishes, split into scheduled runs and conversations. ## What you get Per job and per desk, monthly: hours saved, money saved at your rates, money spent, and the net. Conversations are counted as spend, so a job that asks you too often shows up as one. ## Red rows Some jobs cost more than they save, usually because the input is messy: a photo instead of a form, a mail instead of a file. The report shows them in red with the reason. You can fix the input or switch the job off yourself. A job that is switched off stays in the report at zero, so next quarter nobody wonders where it went. ## What it does not count Mistakes that did not happen, and money that arrived sooner. Both are real and neither can be proven, so neither is claimed. --- # What it runs on Section: Data and access Address: https://scytian.com/docs/what-it-runs-on Updated: 2026-09-14 Your IT will ask what this is built on, so here it is in plain terms. ## The models Agents run on **Anthropic's Claude models**, under a business agreement: no training on your data, and retention only as those terms allow. Anthropic is our only model provider, which means one set of terms in your file and no question about where a document went. Most of what happens never reaches a model at all. A step that runs as a script sends nothing, and most steps are scripts. See [Script first, agent when needed](/docs/script-and-agent). ## The runtime The part that gives an agent its tools, its turns and its access is **Anthropic's Claude Agent SDK**, running inside the container that belongs to your company. It is not a shared machine and not a browser session pretending to be a colleague. We did not build our own agent harness, on purpose. Keeping one correct is a full time job for a company whose whole product is that harness, and the companies that build their own end up maintaining it instead of using it. You do not build one either, which is the point of paying for this at all. ## The part that is ours The harness makes an agent possible. It does not make it something you can hand a process to. That is the layer we build: - **A plan approved before anything is built.** See [Jobs and plans](/docs/jobs-and-plans). - **A gate before it goes live.** Scored on your own cases; below the agreed number the switch stays off. See [Measured before it goes live](/docs/measured-before-live). - **Isolation.** One container per customer, with only the connections that job needs. See [Where your data lives](/docs/where-your-data-lives). - **Script first.** The mechanical work costs nothing and gives the same result every time. - **Written norms and rules,** so behaviour does not depend on how a question was phrased. See [Norms and rules](/docs/norms-and-rules). - **Three ways out,** decided in the plan rather than by the agent at runtime. See [Three ways out](/docs/three-ways-out). - **A timeline with a cost on every run,** and an ROI report that says when a job stops being worth it. ## What this means for you Model versions change over time. Keeping up with them is our work, not yours, and a change that affects a job is measured on your own cases before it is used, the same way the job was measured the first time. Your data is not training data. Your records stay in your systems. What goes to a model is the document or record a step is working on, and nothing else. --- # Connections and keys Section: Data and access Address: https://scytian.com/docs/connections-and-keys Updated: 2026-09-14 An agent reaches a system through a **connection**. Four kinds exist. **An API key or token** that you paste once. **A sign in**, where you authorise Scytian in your provider's own window. Microsoft 365 works this way, so nobody has to register an application to get started. **A service account**, for systems that work that way. **An MCP server**, when a vendor offers one and the job needs it. ## What happens to the value It is encrypted the moment you save it and stored in your own container. It is never shown back, not to you, not to us, not to the agent. The agent calls a connection **by name** and the platform opens the door, so the value cannot end up in a prompt, a log or a chat. If a key is ever pasted into a conversation by mistake, treat it as exposed and rotate it. The platform redacts what it recognises, but the right answer to a key in a chat is a new key. ## Scope The narrowest access that does the job. Read only where reading is enough. One mailbox rather than the domain. A bank connected to be read, with no payment rights anywhere on the platform to grant. Each connection records who granted it and when, and each job carries only the connections and tools it needs. ## Taking access away Revoking a connection is one action on your side and it stops the jobs that use it. Nothing else breaks, and the timeline keeps the record of what was done while the access existed. --- # Where your data lives Section: Data and access Address: https://scytian.com/docs/where-your-data-lives Updated: 2026-09-14 ## Your systems Your accounting, your CRM, your mailbox, your shop. The platform reads a record, acts on it and writes the result back through the system's own interface. Nothing is copied out to live somewhere else, and there is no database of ours holding your invoices. ## Your container Your agents run in a container that is yours alone, in the European Union. One customer, one container, with no credentials of the platform inside it. No agent can reach another customer's container, and that boundary is a property of the platform rather than a setting. Running the part that touches your systems inside your own network is available on request. ## The platform The platform holds the process rather than your records: the plans you approved, your rules, the run log and the encrypted values behind your connections. That lives in the platform's own database in the European Union, separated per customer. A connection value is decrypted and placed in your container only for the run that needs it, and it never appears in a prompt, a log or a chat. The agent works with the name of a connection and never receives the value itself. See [Connections and keys](/docs/connections-and-keys). ## The model call When a step needs judgement, the document or record being worked on is sent to Anthropic's Claude models under a business agreement: no training on your data, and retention only as those terms allow. Anthropic is our only model provider. A step that runs as a script sends nothing to a model at all, and most steps are scripts. See [What it runs on](/docs/what-it-runs-on). ## What is kept and for how long Plans, rules, encrypted connection values and the run log, for as long as you are a customer, exportable at any time. ## Leaving You keep every plan in plain language, the list of connections and the full run log. Your records never moved, so there is nothing to migrate back. --- # Limits and queues Section: Data and access Address: https://scytian.com/docs/limits Updated: 2026-09-14 Limits exist so one busy job cannot take the whole workspace with it. They are visible, and nothing is dropped silently. ## Runs of the same job Script runs of one job go one after another by default, which keeps writes in order. The part that needs the agent can be allowed to run several at a time when a job has to keep up with a burst, and that is a setting on the job rather than a surprise. ## Queues When a job is busy, the next request waits in a durable queue instead of being refused. The queue survives a restart of the platform, keeps its order, and each waiting run carries its own input, so a burst of ten documents produces ten runs with ten documents and not ten copies of the last one. ## Webhooks Sixty requests per minute per token, and a payload of up to 256 kilobytes. Above either, the caller receives an answer that says so. See [Webhooks](/docs/webhooks). ## Capacity Each container has a fixed amount of memory and a ceiling on how many runs happen at once. When the ceiling is reached, work queues rather than failing. Growing that ceiling is a change we make on your workspace, not something an agent can do to itself. ## Long runs A run that would take longer than its limit is ended and reported, so nothing hangs invisibly. What it did until then stays on the timeline. --- # Libraries Section: Data and access Address: https://scytian.com/docs/libraries Updated: 2026-09-14 Scripts run inside your container with a standard set of libraries already installed: spreadsheets, Word documents, PDF, tables, and a document converter. Those cover most of what a back office process needs. ## Asking for one more When a job needs a library that is not there, the agent asks for it rather than installing it quietly. An agent cannot add a dependency during a run, because a library installed on the fly disappears on the next restart and takes the job with it. ## What is checked before it is installed The package is looked up and pinned to an exact version. Known vulnerabilities are checked and a critical one refuses the request. Everything the package would bring with it is checked as well, not only the package itself. A name that collides with something the platform uses is refused. ## Who decides A request that passes every check can install itself and you get a report. Anything with a finding becomes a real question with an Approve and a Reject, in the inbox, with the finding in front of the person deciding. ## What you see The list of libraries in your workspace, who asked for each one, when it was added and why. Total size is capped per workspace, so a container cannot grow without anyone noticing. --- # For AI assistants Section: For AI assistants Address: https://scytian.com/docs/for-ai-assistants Updated: 2026-09-14 These pages are written to be read by a person and by a model, so the assistant your company already uses can answer questions about Scytian without guessing. ## Every page as plain text Add `.md` to any page address and you get the source markdown instead of the styled page. ``` /docs/webhooks the page /docs/webhooks.md the same page as markdown ``` ## The whole documentation in one file ``` /docs/llms.txt an index: every page, its summary and its address /docs/llms-full.txt every page, in full, in one file ``` `llms.txt` is small enough to paste into a conversation. `llms-full.txt` is the whole thing for an assistant that can read a long document. A useful first instruction for an assistant: ``` Read https://scytian.com/docs/llms-full.txt before you answer questions about Scytian. Cite the page you used. ``` ## How to cite a page Each page has a stable address, a title and a summary in its front matter, and a date of last change. Quote the title and the address. Do not quote a version number, because these pages are updated with the product rather than released in versions. ## What is not here Pricing, contracts and anything specific to one customer. Those are not part of the documentation. ## Planned A documentation server that an assistant can connect to directly, so it can search these pages instead of downloading them. Until it exists, the files above are the way in. ---