Org web apps, a leaner starting context and a guided path to self-hosting

This week's Keyboard release adds a new way for teams to put AI agents to work, building small internal apps, and gives admins more control over what the agent sees and how a self-hosted deployment comes together. Here's what shipped and who it's for.

Org web apps: build an app from chat, share it with your team

For CIOs and IT Admins. Your AI agent can now build an app for you and publish it to your organization's own Keyboard web app site, then hand back a link. Admins deploy that site once from the new Web apps page in the dashboard, which also shows when the organization's copy has fallen behind the latest template. Template updates are applied from that page when an admin chooses to; nothing is pushed into an organization's site automatically.

From the AI client, the agent can:

• list the apps you can open, with their owner, visibility and your role;
• publish a new app or replace an existing one, and return its link;
• read an app's current source so it can edit it rather than rewrite it;
• check the latest build status;
• share an app org-wide, or with specific teams and people, and name who else can manage it;
• delete an app.

App admins and org admins can also work on apps they don't own.

For CISOs. An app reaches company systems only through Keyboard, and only through the connections declared for it. The agent never handles the site's repository or hosting credentials; publishing goes through Keyboard using the organization's own configuration.

Web apps are controlled by an org-wide switch that is off by default. Until an admin turns it on, members' tools report that web apps aren't available rather than failing.

Why it matters: the internal tool someone needs for a one-off job (a lookup page, a small form, a report view) can be built from a conversation and shared with the right people, without a separate hosting project and without widening access to company data.

A compact starting context, and org notes the agent can't miss

For CIOs and IT Admins. Every Keyboard session starts with the agent loading context about the organization: connected apps, available tools and the notes admins have written. As an organization connects more apps, that context grows.

Admins can now turn on compact starting context under Settings → Model settings. In compact mode the agent starts with app names, plus a short flag when something needs attention, such as a pending connection or an org note. It then fetches full details for just the apps and notes a task needs.

Org notes, the instructions admins write for the agent, gain tags. An admin can tag a note by topic (for example "slides" or "images"), and tags show as chips on the notes list. In compact mode:

• the agent sees a topic index at the top of its context, listing every tag and the notes behind it;
• notes whose tags match the topics a task declares are expanded automatically on the first call;
• the agent is told that org notes are admin instructions to read before it starts work.

Why it matters: the starting context stays small as the number of connected apps grows, and the guidance admins write reaches the agent when it's relevant instead of getting lost in a long list.

A guided setup for self-hosted deployments

For CIOs and IT Admins. The self-hosting tab in the dashboard is now a step-by-step wizard. Admins choose their cloud, how to deploy (a guided setup where it's supported, or a manual one) and the shape of the deployment. The wizard then shows only the steps that setup needs, as a numbered checklist that ticks off from live status: access tokens, check-ins from each deployed component, the saved self-hosted address and the registered sign-in URLs. A verify step shows the address each component is configured to use, with a link to that component's health check.

Choices are saved per organization, so an admin can pick up where they left off.

Why it matters: running Keyboard in your own infrastructure becomes a guided checklist rather than a document to interpret, and the dashboard shows which steps are done.

Self-service sign-in URLs for self-hosted organizations

For CISOs and IT Admins. A self-hosted dashboard or connection page signs users in through Keyboard. Until now, each customer domain had to be added to an allow-list by hand. Org admins can now register the exact callback URLs their deployment uses, with one-click suggestions built from the addresses their own components report.

Each URL is bound to the organization that registered it. A sign-in through a registered URL can only be completed for a user of that organization, and only registered URLs are ever used as redirect targets.

Why it matters: self-hosted customers can set up sign-in on their own domains without waiting on a manual change, and a URL registered by one organization can't be used to sign in users from another.

Getting started

Web apps and compact starting context are both opt-in, so an org admin can turn them on from the Keyboard dashboard when the team is ready. Self-hosted organizations will find the new wizard and sign-in URL settings on the self-hosting tab. To learn more, visit the Keyboard docs.