On Team and Business
Development, the content writer and setup assistants
The same agent, put to three more jobs: changing your product when your team asks, writing blog articles from what your product really does, and helping your customers set things up inside your portal. A person stays in charge of each.
Development (beta)
Ask for a change to your product, in a chat
The people you choose can ask the agent to change your product: its code, its website, its wording or its pictures. They talk it through, the agent opens a pull request, and it's merged and deployed when they say so. The agent then watches the deploy and says when the change is live.
- 1
Someone with Development access opens a request and says what should change, as they would to a developer. They can attach pictures or files, such as a photo for the About page.
- 2
The agent reads your code and the attachments, asks anything it needs, and shows its plan: what it will change, in which repository and files, and how risky it is.
- 3
They click Build it, or tell the agent to go ahead. The agent makes the change and the service opens a pull request. Asking again adds to the same pull request.
- 4
They review it on GitHub or GitLab, then press Merge. The service merges it, never the agent.
- 5
The agent watches the build and the deploy for up to 30 minutes, and says when the change is live, or what went wrong.
You choose who can use it
Owners and admins give Development person by person and platform by platform. Only those people see the Development tab and its requests.
Merge and deploy without asking
Someone with Development access can tick it for a request. That request's changes are then merged and deployed as soon as they're ready, without anyone reviewing them. The agent still asks first if a change could lose data, take money or lock people out.
Kept away from your requesters
Development requests never reach your requesters or your ticket system. They stay out of the queue, the ticket list, metrics and notifications.
A beta: go carefully
The agent can't run or test its changes, so a change can be wrong or break something else. Review the pull request before you merge. You're responsible for what you deploy: see the terms for Development.
The agent changes only repositories that allow fixes, and only when code changes are switched on for your organisation.
Content writer
Blog articles from what your product really does
The content writer suggests topics and drafts articles that help your readers and bring people to your website from search. It writes only about what your own help pages and notes describe, and lists what each claim is based on. A person approves every article before it's published.
| Step | What it does | What it can see |
|---|---|---|
| Market research | Looks at the public web: who else writes about your field, what your readers ask, and what nobody answers well. It looks again every two weeks. | Only public web pages, your platform's name, your public website, your audience, your writing guidance and the titles you already published. Nothing private. |
| Ideas | Suggests topics, each with who it is for and what a reader would search for. | Your help pages, your notes about your system, the product's repositories (read only) and the research. No web access. |
| Writing | Writes one article and lists what each claim is based on. | The same as for ideas. No web access. |
Two ways to work
It suggests ideas for you to pick, a batch at most once a week. Or it writes by itself, from 1 to 14 articles a week. Either way, nothing is published until a person approves it.
Style checks
Each article is checked for phrases that sound machine-written, long dashes, file paths from your code and anything that looks like a key. Anything found is listed for a second look. You decide.
Publishing to your website
An approved article can be sent to your own website as a signed web request, or just marked as published. Unpublishing sends a second message, so your website can take it down.
What it never does
It never publishes without approval, never makes up features, and never changes your code or systems. Market research never sees your code, your settings or anything private.
Setup assistants
Your customers set things up by chatting
A setup assistant sits in your own portal, where your customers are signed in. They say what they want, such as a booking form for the hall with a deposit, and it sets it up in their account, in your system. It shows exactly what it will change, and changes it only when the customer presses Approve.
Setting one up
- 1
Connect your API: its address and its OpenAPI description. Each endpoint becomes an action, switched off.
- 2
Switch on the actions it may use, and describe each in plain words. Reads run when needed. Changes wait for the customer's Approve.
- 3
Write its instructions, choose the Claude model it answers with, and add one piece of code to your portal.
- 4
Your portal's server says who the customer is, and gives the assistant a short-lived key for that customer only.
How it stays safe
Only the actions you choose
It can call only the actions you switched on, at your API's address. Nothing else.
The customer's own access
It uses a short-lived key for that one customer, so it can never do more than they could by clicking. We never store that key, and the AI never sees it.
Changes wait for Approve
The customer sees each step and presses Approve or Not now. Nothing goes to your team for approval first: the customer decides, for their own account only.
No passwords or payment details
When something needs them, such as a payment gateway, it sends the customer to the right page of your portal instead.
A full record
Every conversation, read, proposal and result is kept for your team, with failed changes marked.
Off at once
Switch an assistant off and it disappears from your portal straight away. Nothing it set up is undone.
It answers with your own Claude API key. Each customer message can take a few model rounds while it looks things up.
Which plans have them
Development, the content writer and setup assistants come with the Team and Business plans. Every plan includes support tickets and chatbots. Compare the plans.
See it on your own tickets
Early access is open to teams who look after systems, their own or their clients'. Tell us about your setup and we'll get in touch.