People often ask us what Factorial's AI features do. The short answer is: less than you might expect, on purpose. We work with coding agents every day, and we think language models are genuinely useful. We're also building software that records how parts are made, and that changes where a model belongs.
Determinism first
A factory runs on records people can verify. A torque value, a lot number, a signoff: each one should be the same no matter who looks at it or when. In a mission-critical environment, the same input should give the same output, and when something looks wrong, a person must be able to trace why.
Language models don't work that way. Ask one the same question twice and you may get two different answers, both plausible. That's fine for a first draft. It isn't fine for the record of how a part was built, or for the number a quality engineer signs off on.
Your data stays where it is
The common approach is to give a model broad access to everything and let it find the answer. That's costly, since every record a model reads is paid for, and it's hard to audit: when a model has read everything, it's difficult to say what any given answer was based on.
So no Factorial AI feature ingests your data on its own. Nothing is sent to a model until someone asks a question, and what is sent is limited and documented.
Ask, as an example
Analytics runs read-only SQL over a stable set of views. Ask lets someone type a question in plain English, such as "How many work orders were completed each week this quarter?", and get a query back. To write it, the model receives three things:
- The question.
- The Analytics schema: the views and columns, which are the same for every organization and listed under Schema on the same page.
- A few written instructions from us on how to write a query against that schema.
No rows and no results are sent. What comes back is a SQL query. Factorial runs it read-only, with the same limits as any query, and shows it right above its results, for you to read, edit, and verify.
The distinction matters. Asking the same question twice may not produce the same query. Running a query is deterministic: run it as many times as you like against the same data and you get the same result. The model writes the query; the query, not the model, produces the numbers.
We show that middle step on purpose. Someone comfortable with SQL can read the query and confirm it counts what they meant, filters what they expected, and joins what it should. An answer you can check is worth more than one you have to trust.
Bring your own keys
Ask uses an API key from Anthropic, OpenAI, or Gemini. A key can be personal, visible and usable only by its owner, or belong to the organization, saved by an administrator for everyone with the Analytics permission. The provider bills the key for each question, so cost shows up where you already manage it, under the limits you already set. Keys are encrypted before they're stored, and Factorial never shows them again.
Administrators are in control
AI features are off by default. Administrators choose how they work in organization settings:
- On, with personal and organization keys. People may ask with their own keys or the organization's.
- On, with organization keys only. Only keys the organization manages may be used.
- Off, the default. Where an AI feature would be, people see a short note that it's turned off.
- Off and hidden. Even those notes are removed.
Factorial keeps every earlier setting along with who changed it and when. And if we ever build a feature that sends more than the schema and a question, it will get its own setting rather than turning on under the existing one.
For bigger work, use your own agent
Ask is built for one question and one query. For anything larger, like a report that takes several queries or an investigation that needs some back and forth, our favorite route is fctl, our command-line interface, with the coding agent your team already uses, such as Claude Code or Codex.
Two new commands make that practical. fctl analytics schema prints the views and columns, and fctl analytics query runs SQL against them. An agent can read the schema, write a query, run it, look at the result, and revise, all in your terminal where you can follow along.
There are no AI keys to set up in Factorial for this. fctl uses a normal Factorial API key, which acts as its user with that user's roles, and Analytics queries can't change data. We recommend a dedicated service account with only the roles the work needs.
We're developers, and this is the route we use ourselves. It keeps the model on your side of the line, under your own account with your provider, with Factorial's permissions applied to every request. It also gives Factorial the same job it always has: answering a well-formed request the same way every time.
We see AI as a helper for writing things you then verify: a query, a plugin, a page. Not as an autonomous actor on production data. The model drafts, a person reads, and deterministic software runs.
Read how asking in plain English works, or see the organization settings that control it.