Anyone who's built seriously with an AI coding agent already knows the single biggest lever on getting a task right: the context the agent has going in. Give it structured, relevant context upfront and it builds accurately on the first try. Make it guess, and you pay for the guessing twice: once in tokens, once in rework. This isn't a new insight. The wider AI coding world converged on it long ago, and on the fix for it: persistent context files, Skills and an AGENTS.md, that travel with the project and tell the agent how this team builds.
What's been missing is a way to bring that discipline into your backend. As of release 2.5, that's what Xano gives you. It's called Knowledge.
Because here's the thing the coding world figured out but rarely governs: an agent's knowledge—its Skills, its standing rules, the harness it operates inside—is itself a form of business logic. It's guardrail-setting. When you tell the agent "always paginate list endpoints," "auth goes through this function," or "never write directly to the production table," you're defining how your system is allowed to be built. That's a rule with the same weight as any function stack. In Xano, it's finally treated that way.
What Knowledge is
Knowledge is a workspace-native library of persistent, team-authored context that the Xano Agent (or your external coding agent of choice) carries into every build. All three pieces are Markdown files; what separates them is when they load and what they carry:
- A workspace AGENTS.md: Your standing rules. The top-level context that holds true on every run: naming conventions, architectural patterns, the team-wide do's and don'ts. It's always included, so keep it lean.
- Docs: Your reference material. Longer-form context the agent pulls in when a task calls for it: domain rules, schema and API specs, how your auth flow works. The agent draws on them by relevance, so the library can grow without weighing down every session.
- Skills: Yur procedures. Step-by-step methods for how your team does something—how you add an endpoint, structure a CRUD group, handle a migration—each able to carry its own reference files.
Author them once, and the agent builds with them every time. And it's not only the in-product agent: the same library reaches the local coding agents you already work in—Claude, Codex, and others—through the Xano CLI and Developer MCP, so your context isn't trapped in a single tool.
What you can actually encode
The easiest way to see the power here is to look at the kinds of instructions Knowledge lets you set—because each one is a guardrail you'd otherwise be re-typing, or hoping someone remembers.
Take a real setup flow. When teams connect an external builder like Bolt to Xano, there's a precise sequence that has to happen or the build breaks: use the correct starter template so all the right resources exist; connect Xano over the MCP with the right transport and OAuth; verify you're pointed at the correct instance and workspace before building a single thing.
Every one of those is a rule you can bake into a Skill. Instead of narrating the sequence in a video or a wiki page nobody re-reads, you write it down once:
- Environment guardrails: "Always confirm the active workspace and instance before building," "never build against workspace IDs outside this list."
- Procedure Skills: "How we connect an external agent," "how we push to static hosting when a build is done," each carrying its own reference steps.
- Convention rules: Naming standards, the auth pattern, the function library you've standardized on, the endpoints that must always paginate.
- Hard don'ts: The two things your team never does, encoded as constraints the agent enforces rather than reminders you repeat.
The more of these you capture, the clearer the picture of what your agent is allowed to do. A Skill isn't a note to the agent—it's the boundary the agent builds inside.
One library, authored your way
Knowledge isn't an external config file you wire up and hope stays in sync. It lives natively in the workspace—and you can author it three ways: by hand in the Xano UI, through the Xano Agent, or from the external coding agents you already use. All three write to the same library, so a developer editing a Skill from their terminal and an SME editing a Doc in the UI are updating one source of truth.
That matters because scattered context drifts. When the rules live in a repo file in one tool, a wiki in another, and three people's heads, nobody's quite sure which is current—and the agent reads whichever it happens to have. Xano’s Knowledge feature gives you one governed library that every agent reads from, in the workspace and in your local tools alike. Authored once, applied everywhere.
Invoke exactly the context you intend
Persistent doesn't mean indiscriminate. Each Skill sets its own inclusion mode—always, on demand, or manual. Always-included Skills load every session. On-demand Skills surface their title and description up front, and the agent pulls in the full file when it judges the task relevant. Manual Skills load only when you name them: type / in the agent composer to attach one or more as persistent, removable pills.
So a billing task gets your billing Skills; an auth task gets your auth standards; a deployment task gets your push-and-verify procedure. You're not dumping the entire workspace's conventions on every prompt, and you're not leaving the agent to guess which rules apply. And before a run, you can preview exactly what the agent will receive—so the library stays curated rather than bloated, however large it grows.
Reviewed and versioned like everything else
Here's where Knowledge stops being a sticky note and becomes infrastructure. Every Knowledge change flows through the same push-and-commit review as any other agent edit. You get a knowledge diff in the push modal and full version history—your team's standards are versioned exactly like your function stacks.
So a change to how your team builds is a reviewable, revertible, auditable event. You can see who changed a Skill and when, compare it against the prior version, and roll it back if it didn't land. Knowledge files can even reference the files and function stacks they describe, tying your context directly to the backend it governs. The context that governs your builds is held to the same discipline as the builds themselves—because it is part of the build.
Governed, not optional
For most teams, the failure mode isn't a lack of standards—it's standards that everyone is free to ignore. Xano’s Knowledge feature closes that gap. Admins can lock and enforce Knowledge—both what's editable and what must always be included in an Agent session—turning your team's conventions from something each builder has to remember into something the agent applies automatically, every time.
This is the same posture Xano takes everywhere it touches agentic development: governance you can actually enforce.
Why this matters
The promise of agentic building was always speed without losing control. The rest of the AI coding ecosystem solved half of it: they made context persistent. Xano’s Knowledge feature closes the other half—it makes that context governed, and it holds it to the same standard as the business logic it lives beside. Without it, your best builder's conventions live in their head and ship inconsistently. With it, those conventions are authored once, attached deliberately, reviewed like code, versioned like code, and enforced by admins—so the agent builds the way your team builds, no matter who's driving the session, or which tool they're driving it from.
Unlike re-explaining your patterns every time, the context contained in Knowledge persists. Unlike the ungoverned Skills-and-AGENTS.md files scattered across repos and CLI tools, it's a governed library native to the workspace—authored in-product, reviewed through the same commit flow, versioned like your function stacks, governable by admins—and carried back out to your local coding agents through the CLI and Developer MCP. Your guardrails stop being advice and start being infrastructure. Reproducibility stops depending on memory, or on which tool you opened, and starts being the default.
Getting started
Open your workspace and head to the Knowledge section. Start by writing down the conventions you already explain most often—your naming standards, your auth pattern, the functions you want reused, the setup steps you always walk people through—as a Skill or two and a workspace AGENTS.md. Then attach them in the agent composer on your next build and watch the output match your standards without you saying a word.
If you're an admin, lock the Knowledge that should never be optional, so every session on your team starts from the same playbook. And because the same library reaches your local coding agents through the CLI and Developer MCP, the standards you set show up wherever your team builds—not just in the workspace. Your standards become something the agent applies, repeatably, every time. Start building for free.
