You author declarative def-objects, register them on one Xano instance, and XanoTS compiles
the whole thing into Xano’s importable bundle.
Build time vs. request time
Def modules execute at build time only: s.* factories return data, and the engine runs
the compiled stack per request — statements in order, a statement’s as: naming a runtime
variable, response the HTTP body. Every dynamic operand is a tagged value — ref("x") a
stack variable, inp("x") an input, auth("id") the caller, c.* a constant — resolved at
request time.
Because operands are tagged values rather than live data, JS operators over them do not
compute. Use expr() and the fl.* filter catalog instead of +, &&, or ===.
Requests share no memory — state persists in tables or redis.
The statement surface
Tab-complete s. to discover the entire statement catalog — s.db.*, s.math.*,
s.array.*, s.text.*, s.storage.*, s.api.*, s.cloud.*, control flow, AI agent runs,
and more. All 214 engine statement surfaces are authorable — every field name matches the
Xano engine, and the emitted shape is checked against bytes a real engine stored. Where a
surface has no stored instance behind it yet, it is built from the engine’s own schema;
Coverage says which is which.
Seed data
Give a table a seed array and those rows ship into the database on deploy, so a fresh
environment comes up with its lookup tables and fixtures already in place.
AI agents, versioned with your code
Your workspace’s own AI agents are configured the same way. knowledge() is the markdown they
read before they act — standing instructions, a skill, or reference docs — and the body is a
real .md file in your repo rather than a string in a def:
So the instructions your agents follow are reviewed in a diff, versioned with the code they
describe, and redeployed with it — instead of living in a console where nothing tracks them.
Where to go next
Tables, fields, statements, values, inputs, and middleware are all in the
Authoring reference; every kind you can author is in
Object kinds.