An assistant per job, built by describing it

Assistants

Playable below - no signup

No code, no prompt-engineering course. Write what it should do, attach the documents it should know, pick the tools it may use, and share it with the people who need it.

Try it below

Live demo

The editor, with real assistants in it

Open one, read its instructions, change the model tier, look at what knowledge and skills are attached. Three sample assistants; nothing you change is saved.

Sample assistants on sample data. The demo has no network access, so nothing you type is sent or stored.

Anatomy

Four things turn a chat box into an assistant

Everything below is a field in the editor you just used, not a professional-services engagement.

Instructions that persist

What it does, how it answers, what it must refuse. Written once, applied to every conversation, for everyone you share it with - so behaviour stops depending on who typed the best prompt that morning. A designer can draft and refine them with you if a blank box is the wrong place to start.

Knowledge it can search

Attach knowledge bases and the assistant answers from your documents, with numbered citations rather than a confident guess.

Tools it may call

Read the thread, file the document, book the slot. Only the tools you enable, only within the permissions of the account that connected them.

Memory, scoped

Facts worth keeping are remembered per user or per project, not pooled into one bucket that leaks between colleagues.

Skills, when the task is specific

Reusable instruction packs the assistant pulls in on demand, instead of one prompt trying to cover everything.

Live demo

And this is what a skill actually is

An assistant pulls in skills on demand — reusable instructions, rules and worked examples that stop you rewriting the same guidance into every assistant. Open one and read it: the house writing style, a tender triage routine, a contract-review checklist. Sample skills, nothing is saved.

Sample skills only. The demo has no network access, so edits are discarded on reload.

Sharing is the part most teams get wrong

Visibility and permissions

An assistant starts personal. Publish it to your organisation or to a specific group and everyone gets the same behaviour - but not necessarily the same reach: which integrations it may use is resolved against the permissions of the person talking to it, not the person who built it. So a shared assistant can never become a way around somebody else's access.

What an assistant can reach

FAQ

Worth knowing

What makes an assistant different from just chatting?

Instructions that persist, knowledge it can search, tools it may call, and memory scoped to the user or project. You build it once and the whole team gets the same behaviour instead of everyone re-inventing a prompt.

Who can see the assistants I build?

You choose: personal, or shared with your organisation or a specific group. Group permissions also decide which integrations it may use on that person's behalf, so sharing an assistant never widens anyone's access.

Do I have to write the instructions myself?

You can, and there is a designer that drafts and refines them for you. Eleven assistants also ship ready-made, including a meeting summariser and a system-prompt designer.

Which model does it use?

Whichever you configure. Six provider adapters ship, plus any OpenAI-compatible endpoint - so an assistant can run against a local model and never leave your network.

Is this on the free tier?

Yes. Assistants, skills and knowledge bases are Community features, with no cap on how many you create.

Build the assistant your team keeps asking for

Most teams start with the one that answers questions about their own documents.