Changelog

Your agent, plugged into your other tools

Agents can now use tools from your other products over MCP. Connect a server once, decide what each of its tools may do, give each agent the tools it needs, and, if you like, let signed-in users plug in their own.

Your agent knows your product well. Your customers' questions, rudely, don't stop at your product's edges: they're about the ticket they filed, the deal in the CRM, the page in someone's workspace. Now you can connect the MCP servers those products offer, once, in the dashboard, and hand their tools to the agents that need them.

The rules are the ones you already know. Every tool is Allow, Ask, or Deny. An agent gets only the tools you tick, and a tool a server adds later arrives switched off. A server with its own sign-in acts as whoever signed in, so a shared or service account is the sensible choice.

You can also let signed-in users connect their own servers from inside the assistant, under Connectors. Their connections stay theirs, working in their own conversations and nowhere else. And on those agents, any of your tools that can change or delete data always asks first.

Steep: see what each person did

Meet Steep. Add one package or script tag to your web app, and your team can read each person's journey through it, step by step, with sensitive values redacted before they leave the browser.

People ask the assistant things like "why won't this work?", and "this" is doing a lot of the lifting. Steep fills in the rest. Install @teaflask/steep, or paste its script tag, and it records what people do in your app: the pages they view, what they click, the fields they change, the forms they submit, and the calls your app makes for them. In the dashboard, each visit becomes a journey, a plain-English timeline you can read from top to bottom.

Steep shows your users nothing and draws nothing on the page. It redacts sensitive values in the browser before anything is sent, its key only works from the sites you allow, and you can delete one journey, or everything about one person, whenever you need to.

Also this fortnight: the doc editor now holds everything a published doc can, from pasted content to numbered lists and images, so what you edit is what your readers see. You can edit a proposed doc update before you approve it. Your changes to an action survive the next scan, and you can edit its arguments directly. You can build GraphQL actions by uploading your schema and operations, no repository needed. The approval card gained "Don't ask again". And help centers got proper share cards, real 404 pages, and an llms-full.txt for the models that read them.

Teaflask, from the AI you already use

Teaflask now speaks MCP. Connect Claude, ChatGPT, or your other favorite LLM provider to your organization, choose exactly what each one may touch, and let a coding agent do your setup for you.

You probably already spend a good part of your day talking to an AI. Now it can talk to Teaflask. Give it your organization's MCP address, and it can read what your users have been asking, draft and publish docs, work through the review inbox, and tune your agents, skills and actions. It goes through the same doors the dashboard does, under the same rules.

You decide how far each connection reaches. Every area (conversations, docs, agents, actions, billing and the rest) is Off, Read, or Read & write, and you can go down to a single tool. A tool we add later starts switched off on the connections you've already made. The keys that run your models and sign your users in never travel over it, whatever you switch on.

It also changes how you start. Copy the setup prompt from our homepage into your coding agent, and it installs the assistant in your codebase, connects itself to Teaflask, checks what your organization is still missing, fills the gaps, and proves the whole thing runs locally before it hands back to you.

Also this fortnight: actions now speak GraphQL, one action per operation your frontend already sends. You can upload an API spec instead of connecting a repository. Owners can remove members and change their roles. And if you switch it on, the assistant remembers signed-in visitors from one conversation to the next.

The assistant is on npm

The assistant is now a public npm package: npm install @teaflask/assistant, one publishable key, three lines of JSX.

Install @teaflask/assistant, import it, and hand it your publishable key. The companion, the command palette and the chat drawer then mount as part of your app, typed and versioned like everything else you depend on.

Two more doors open with it. The companion can wear your own mark instead of ours, from a component or an image URL. And if you'd rather build the whole face yourself, a headless entry hands you the live conversation (sending, stopping, approvals, the streamed replies) with none of our chrome attached.

Your components, in the conversation

When the agent calls one of your tools, your own code can now draw the result. Register a view for any tool you own, and the conversation shows that call the way your product would.

Until now every tool call wore the same tidy, generic card. That's fine for a weather lookup. It's a little sad for an order that has line items, a status, and a tracking number your product already knows how to draw. Now you can register a view of your own for any tool you own, keyed by its name. The conversation renders that call with your markup, in whichever light or dark theme the assistant is painting.

The agent can bring help

A big job no longer has to fit in one conversation: your agent can hand self-contained pieces of it to sub-agents that work in the background and report back. It can never hand them more than you gave it.

Some questions are one question. Others are really twelve, and until now the twelve took turns. Now your agent can hand a self-contained piece of the job to a sub-agent — several at once, each with its own brief — and carry on while they work. You can watch them go, open any one of them mid-flight, ask a finished one a follow-up, or stop the whole thing when you've changed your mind.

Bringing help never widens anything. A sub-agent inherits a subset of what you already granted the agent, never a tool you withheld, so nothing becomes reachable by hiring out. And dispatching is itself a permission: leave it on Allow, or set it to Ask and be the one who decides the job is worth the help.

Steadier, and sharper

Sign-in went passwordless, the dashboard and help center got a finishing pass, and a run of releases made the platform quietly steadier.

Signing in is now a code by email or a Google account — no password to invent, store, or forget.

The rest of these weeks was polish and steadiness: sharper reading and dashboard surfaces, and reliability work whose whole point is that you never see it.

Self-serve, end to end

From a fresh account to a live assistant in one sitting: sign up, follow the install page, and your copilot is in your product the same day.

Everything between signing up and a live assistant is now self-serve. The install page assembles the exact instructions for wiring the assistant into your product — you paste, it works.

The same week made Teaflask a fair place to be a tenant: published terms and a privacy policy, with acceptance recorded at signup, and fair-use limits so one heavy neighbor can't crowd out everyone else.

Drop in a script tag

The assistant now lives in your product: one script tag, a floating companion or a command palette, streaming that survives a dropped connection — and a Conversations view where you read every exchange your users have.

Distribution became the easy part. Paste one script tag and your copilot is in your app — a floating companion, a docked panel, or a command palette — with the conversation following your user across pages. Answers stream in token by token, and a dropped connection resumes mid-sentence instead of starting over.

On your side of the glass, Conversations shows what your end-users are actually asking, and transcripts narrate what the agent is doing in plain language while it works. You can also bring your own model key and run against your own account.

The agent can act now — on your terms

Point Teaflask at your API and its endpoints become actions the agent can take, each one set to Allow, Ask, or Deny. Approvals can wait days without losing the run, and every decision lands on the record.

A scan reads your API and files what it finds as a catalog of actions — named, described, and inert until you grant them. Every action carries one of three words: Allow, Ask, or Deny. Ask is the interesting one: the run parks, a human decides — in a minute or next Tuesday — and the work resumes exactly where it stopped, because losing a whole task over one approval would be absurd.

When your API changes, a rescan keeps the catalog current. And everything the agent does — every action, every approval, every denial — is written down where you can audit it.

Meet your agent

Teaflask now grows an AI agent on top of those verified docs: configure it, give it skills and memory, rehearse it in the playground, and publish it when — and only when — it's ready.

An agent here is configuration, not code. You write its prompt and its skills, decide what it remembers, and it answers from the docs Teaflask has already verified — grounded by construction, not by hope. The playground lets you rehearse a draft against the real thing and publish only what passed.

Two properties came built in rather than bolted on: every run executes inside its own isolated sandbox — its files, its tools, and nothing else — and anything sensitive can be set to wait for a human yes before it happens.

Introducing Teaflask

Connect a repository and Teaflask writes your docs, publishes them as a hosted help center, and — the part we're proudest of — keeps proving them: every factual claim is tested against your code and re-tested when the code changes.

Documentation has a physics problem: the code moves and the prose doesn't. Teaflask starts there. Connect a repository and an agent reads it and drafts your docs; you review, edit, and publish them to a hosted help center. Each published claim carries its own verification, re-run whenever the code changes — and when the code contradicts the docs, you don't get silent staleness, you get a proposed rewrite as a diff waiting for your review.

Around that loop is everything docs need to live somewhere real: a proper editor, history you can restore, and a review inbox where drafts and drift wait for a human.