Publish an agent¶
Publishing turns an agent you've built into something other people can actually use — a live page with its own web address that you can share, install, or connect to.
The main assistant stays private
Publishing is for agents you've built. Your main assistant is a system instance scoped to you rather than an agent of its own, so it can't be published — the platform declines the request. To share what it does, build a dedicated agent for it.
Give it a handle¶
When you publish, you give the agent a public handle — a short, readable name of your choosing. Its page then lives at a clean address like yourdomain/chat/support-bot. The handle is the link; there's no long random share token to manage.
Choose who can open it¶
Set an access mode that fits how widely you want the agent used:
| Mode | Who gets in |
|---|---|
| Open | Anyone with a platform account — admitted automatically on first visit. |
| Password | Visitors sign in, then enter a shared password you set. |
| Organization | Members of your organization — plus anyone you invite personally. |
| Everyone on the platform | The audience of the platform's own built-in agents. It is not something you turn on for the agents you build. On those agents the user always pays, and there is no allowance. |
| Private (invite-only) | No one without an invite. |
For private and organization agents you can send a personal, email-bound invite (tied to one address, expiring, revocable) or hand out a reusable invite link. For an organization agent, that's how you share it with someone outside the organization — a client or contractor gets access to this one agent without joining your organization.
An agent built in an organization workspace starts out as Organization and can be switched to any other mode. Whatever the mode, when the owner pays, the organization's balance pays.
Choose what each person can do¶
Getting in is one thing; what a person can do with the agent is another. Each person has an access level:
| Level | What the person can do |
|---|---|
| Can use | Chat with the agent and use its published page. |
| Can copy | Everything in Can use, plus Make a copy — their own copy of the agent, which they then own. |
| Can edit | Everything in Can copy, plus building the agent together with you in the builder. |
You set the level per person, in the people list of the agent's access settings and in the email invite. Organization members are listed there too, and you can raise any of them. People who join through the link, the password or an open agent start at Can use, and you can raise them afterwards from the people list. To add someone straight at Can copy or Can edit, send them an email invite — that is the only way to add a person above Can use. Invitations need a published agent.
Revoking a person's access also resets their level: if you invite them again, they start over at the level you choose then.
What a copy contains¶
A copy has:
- the prompt and settings,
- skills and workflows,
- connection slots — without credentials, so the copier connects their own accounts,
- the names of environment keys — without their values,
- the app and backend code,
- the database structure — without any data,
- the documents of knowledge bases marked Use for everyone. They are re-indexed for the person who copies, at their cost, so the knowledge appears gradually rather than all at once.
A copy never contains secrets, data, conversations, memory, or knowledge bases that are not marked Use for everyone. When you give someone Can copy or Can edit, you are warned about this before you confirm.
Share for editing only with people you trust
An editor can change how your agent behaves. Give Can edit only to people you would let work on the agent themselves.
Every visitor signs in with their own platform account first, whatever the mode. Opening an agent without an account — the old anonymous link, or a password alone — is no longer possible.
Choose who pays¶
You also decide who covers usage. That choice is the agent's default:
- You (the owner) pay from your own balance, or
- The end-user pays from theirs.
A person using the agent can pay from their own personal wallet, or from an organization they belong to, or leave that default. They choose under Payment in the agent's settings. It is a separate item next to Connections: on the agent's page, in the chat's agent settings, and in the mobile apps. It is available to everyone who uses someone else's agent. The list is Agent default plus the wallets they can use. Save wallet changes only who is charged for their use of this agent: chat, voice, images and video, API calls, and workflow runs. It does not switch their workspace, move their conversations, or change which accounts the agent connects to.
Leaving Agent default follows the choice above. Choosing their own wallet never makes you pay when the agent is set to The end-user pays. If the wallet they choose is the same one that already pays for the agent — yours, or your organization's when the agent is published to it — that use still counts as you paying.
When end-users are billed, they see a clear "this uses your balance" notice before chatting. If the paying balance runs out, visitors see a notice — the payer gets a top-up prompt; others are told the owner has been notified. When you pay and your balance is out of credits, the person can choose Pay from my wallet and continue on their own money. If a wallet they chose is revoked or deleted, they have to choose again. Donkit does not silently switch them back to your balance. New paid work waits until they do. Work that already started is still paid from the wallet it started on.
In the people list, each person has a Monthly cap: a monthly credit allowance for use you pay for on this agent. On an agent published to your organization, that is use the organization's balance pays for. Leave the field empty and there is no allowance — no monthly limit. Zero stops new use that you pay for. Use the person pays for themselves is not counted against it. Your own use of the agent is not limited by anyone's cap. The allowance does not cover building the agent, evaluations, or optimization. Next to the field you see what they have already used, and when it resets.
To remove an existing cap, clear the Monthly cap field and save it, including in the Android app. This restores unlimited sponsored use without changing the person's wallet choice.
The allowance is checked before each model request, including the ones that come after tool calls. A reply in progress can stop midway once the sponsored spend already recorded for that person reaches the allowance; what was already used is charged. Several uses at once can all pass before their charges are recorded, so the total can finish above the allowance. The allowance resets with the billing period of the wallet that pays for them. Changing the number does not erase spend already recorded this period.
When the allowance is used up, their chat says the owner's allowance for this agent is exhausted, shows the date it resets, and offers Choose a wallet. Saving a wallet does not rerun the message or the run — they start it again. Donkit does not move that work onto their own money by itself.
The same choice covers the agent's workflows: a run someone starts — with Run, by asking the agent in chat, or through their own schedule or webhook — is paid the way their chat would be. Your own runs always draw on your balance — or, on an agent published to your organization, on the organization's balance, as in chat. When you pay and they have left the default, other people's schedules and webhooks spend your credits each time they run. When they have chosen their own wallet, those runs spend that wallet instead.
If you have joined the affiliate program, agents where the end-user pays also earn you a share of the paid credits visitors spend on them. On an agent you pay for, a visitor who chooses to pay from their own wallet earns you the share too. Agents published for an organization are outside the program.
Share with another company¶
To let people from another company use an agent, publish it to your organization and invite the person from that company by email or with the reusable invite link.
In Payment they choose their own organization's wallet. That organization pays for their use, and it shows on that organization's usage page.
Who sees what:
- You see the use that is counted against your own balance, per person, with name and email. Use their organization pays for is only counted in totals, never with a name.
- The other company sees the use of its wallet on its own organization's usage page.
Share workflows, knowledge and API access¶
More sharing settings, alongside access and billing, decide what people using your agent can reach:
- Let shared users run workflows lets the people you share the agent with run its workflows: from the Workflows tab of the agent's page or by asking the agent in chat, with a schedule and a webhook of their own. Each of their runs acts as them — on their own connections wherever the agent asks each person to connect their own, and on yours for the connections you share (see Whose run it is). They see what each workflow is for, not what happens inside its steps, and you don't see their results: of their runs, you see only the ones that failed, without their content (see Workflows on a shared agent). It's on unless you turn it off; turning it off stops their schedules and webhooks.
- Use for everyone, set per knowledge collection, controls whether that collection also grounds answers in other people's conversations with the agent, not just your own. It's off by default for a newly linked collection; turn it on in the agent's sharing (Publish → access) settings once you want everyone to benefit from it. People never browse the collection directly — only the agent reads it.
- Let users create their own API keys lets anyone with access to the agent generate their own API key from the agent's page, instead of only you creating tokens for them. See API access for what a user's key can do and how it differs from yours.
What people get¶
The published page shows the same chat as your own main assistant — canvas included — as a panel next to the agent's own interface, if it built one. An agent with no interface of its own opens straight into the chat. When the agent's work needs the canvas, it opens there in place of the interface, with App | Canvas tabs to switch back and forth; the panel button in the top-left corner hides and shows the chat. On a phone people see one of app, chat, or canvas at a time and switch with the bar at the bottom. The conversation stays on screen while the agent answers: once there's a file, Canvas appears in the bar, and the canvas opens when they tap it.
The agent's own interface behaves as it does in the Builder's preview: it can ask people to confirm an action, show an alert, and use the microphone once they allow it in the browser.
A button that asks before it starts the agent's work shows the question in the page itself, where the button is, with one button to confirm and one to cancel. The agent starts only after the person confirms.
An agent's own interface does not print inside the Android, iPhone, iPad and Mac apps. For that reason the Builder adds no Print button: the interface offers a document as a file to save (see The agent's interface in the apps). If your interface has only a Print button, ask the Builder to add a download.
Publish again to update the published page
The published page keeps the interface as it was built when you last published. Improvements to the parts every interface is built from — buttons and tables, the way the page fits a phone screen, the way it asks for accounts inside the mobile apps — show up in the Builder's preview on their own. They reach the published page when you open the publishing settings and press Update publication, which also makes your current draft live.
Older published agents
An agent published before this change keeps showing its own, older in-app chat until you republish it — after that it gets the shared chat and canvas above.
When something goes wrong¶
Visitors only see an error notice for failures they can actually act on:
- Chat failure — their message didn't go through: "Couldn't send your message. Please try again."
- Platform failure — a request failed on Donkit's side: "Something didn't load. Please try again."
- Connection loss — a single "Connection lost." notice that clears by itself once the connection is back.
Errors inside the agent's own generated code are not shown to visitors — there's nothing they can do about them. You see those errors in the builder preview instead, where each one carries a Fix with AI action that hands it straight to the builder chat. To investigate something a visitor reported, open the agent in the preview and repeat their steps.
The action reports what actually happened to it: Sent to builder once the builder has the error, Queued — builder is busy when a build is already running (it goes in as soon as that finishes), and Builder didn't answer — retry if nothing picked it up, which usually means the builder is not open. Only that last state is worth clicking again.
Republish to show the setup window
If the agent uses per-user connections or parameters (see Shared vs per-user connections), each end user sees a setup window the first time they use the agent, prompting them to connect or pick from their Connections library and fill in any parameters marked "Filled by each user". This window only appears after the agent has been (re)published with those settings — publish or republish the agent for it to show up. v1 agents don't support per-user connections, so no setup window appears for them.
Install as an app¶
Every published agent can be installed as a standalone app on a phone or desktop — "Add to Home Screen" on iOS, and an install prompt on Android/Chrome. It launches straight into your agent under its own name and icon.
In the Android app, the pin button in an agent's chat header offers the same shortcut for a published agent, plus two Android-only ones for the app itself — one that opens straight on the chat, one on the agent's own interface. Installing the PWA still has to happen from the browser; the app can only hand you the published page there.
Donkit Desktop¶
There's also a Donkit Desktop application — a desktop shell for the platform with auto-updates and a "start with Windows" option. It can turn your own machine into a device that runs agent tasks locally (see Devices). Download it for Windows; an offline installer is available for company rollouts.
Branding¶
A per-agent custom look comes from building a custom-UI agent — the agent's own front-end is its branding.
Distribution options today
The supported ways to distribute an agent are the shareable link, PWA install, the desktop app, and the API. A website-embed widget/iframe and a per-agent color/logo theming panel are not part of the product today.