Skip to main content

📬 Beak AI Runtime – Release Notes

Changelog for agent execution, delivery channels, approvals, and notifications.

Note: This changelog starts at version 6.0.0. Entries below cover changes recorded from that release onward and are not a complete history of earlier Runtime versions.

Version 6.0.0​

A new tenant arrives with the Runtime already set up​

When a tenant is created, the Runtime now sets itself up for it: its schema, the shared agent tables, the built-in prompts, credential types, connector and notification templates, and the tenant's own encryption key. Previously all of that arrived by copying an existing tenant, which meant a new tenant could not be used until an engineer ran that copy.

  • The tenant gets its own encryption key, generated for it. It is never shared with another tenant, and the development key can never reach a real one.
  • A setup checklist replaces guesswork. The Runtime reports what is still needed — an AI provider and a Hub connection are required; notifications and chat channels are optional — and each one completes on its own as soon as the thing it asks for exists.
  • Nothing is asked twice. A tenant that was already configured shows its steps as complete the first time anyone opens the wizard.

On by default for newly created tenants; existing tenants are untouched. See What Each Product Sets Up.

Every tenant's shared agent schema is brought up to date when Runtime starts​

When Beak AI Runtime starts, it now applies the shared agent schema — the tables that Beak AI Studio and Runtime both read, such as agents, credentials, datasources and MCP servers — to every active tenant's database, not only the platform's own. A tenant registered on the platform receives those tables on the next Runtime restart, and a tenant whose tables are behind is brought current before Runtime accepts traffic. A Runtime deployed for a single tenant updates only that tenant.

Previously Runtime only ever updated the platform tenant's database, and a failure while doing so was written to the log and otherwise ignored.

  • What changes for you — Nothing to configure; this is on by default and runs on every start. The user identity table Runtime keeps per tenant is now versioned with the rest of the Runtime schema, so it is created for new tenants the same way.
  • If a migration fails — The new version does not start and the previous version keeps serving. The problem shows up as a failed deployment rather than later as failed requests for one tenant.

See Platform Administration release notes.

Unified-login sessions no longer expire after 15 minutes​

If you reach Beak AI Runtime through unified login, your session now lasts as long as your single sign-on session allows — up to 8 hours on a standard tenant — instead of returning you to the login page roughly every 15 minutes. The renewal request was previously rejected by the browser on tenant-branded addresses — your own company domain, or a <tenant>.beakops.com address — so only users on the default product address were unaffected.

On by default; no configuration, and no change to your tenant's session or idle timeouts. A password sign-in on Beak AI Runtime's own login page is unaffected.

See Platform Administration release notes.

Notification templates you can write, in HTML, once for every channel​

Agent notification templates can now be created and edited, from Beak AI Runtime under Configure → Notifications. Previously the agent could use a stored template but there was no screen to write one for an ordinary agent, so agents composed every notification themselves. See Agent Notifications.

One body, every channel. Write the message once in HTML. Email sends your markup; Microsoft Teams and the in-app bell receive a plain-text rendering derived from that same markup, with paragraphs and table rows preserved rather than run together. A Plain-text override is there for when the chat wording should be shorter, but leaving it empty is what keeps the channels saying the same thing. Values filled into {{variable}} placeholders are escaped, so content arriving from a ticket cannot change the formatting.

Save & preview shows both renderings side by side — the email as a recipient sees it, and the text Teams and the bell receive — so a body that reads poorly once formatting is removed is caught before it is sent rather than after.

Categories. A template is marked Informational, Success, Warning, Critical or Security. The category sets the coloured label at the top of the email and appears in the list the agent chooses from, so it picks wording that matches what happened instead of inferring urgency from the template's name.

On by default? No change to existing behaviour on upgrade. The Notifications capability remains off by default per agent, existing templates keep working exactly as before, and agents with no templates continue to compose their own messages. Nothing needs to be re-authored.

Approval email templates and agent notification templates are now managed in one place, on the same tab. Existing approval email overrides are migrated automatically and are unchanged.

Conversation presets — opening messages and standard answers, set once per agent​

An agent can now greet people and answer its most predictable questions without that behaviour being configured channel by channel, or written into its prompt. Both live on the agent, under a new Conversation tab in Runtime (Configure → Conversation) and a matching Conversation section in Beak AI Studio's agent editor. See Agent Configuration.

Opening messages. A Welcome message opens every new conversation; a First-time message is shown once per person, ever. The once-ever rule is now tracked per user per agent rather than per channel, so someone who saw the introduction in Teams will not see it again in web chat. Both support {first_name} and {agent_name}.

Standard answers. A list — as long as you need — of fixed replies for known questions. A match returns your text word-for-word without calling the model, so the answer is exactly what you wrote, arrives immediately, and costs no tokens. Match on keywords, a contained phrase, the exact message, or a regular expression; optionally add example phrasings so wording you did not anticipate still reaches the right entry. A per-entry switch lets the agent phrase the answer instead, when it needs adapting to the conversation.

Entries are checked from the top and the first match wins, so a Try a question box reports which entry would answer a sample message — the only way to catch one rule shadowing another before a user does.

On by default? No. An agent with nothing configured behaves exactly as before: no opening message, and every question goes to the agent.

Note: Changed behaviour — the per-channel fields are gone. The Teams channel's Greeting response and Welcome message, and the Embed channel's Welcome message, have been removed from those cards. Text you had configured was migrated onto the agent automatically, so nothing needs re-entering — but it now applies on every channel rather than only the one it was set on. If you had deliberately given Teams different wording from the embedded widget, review the Conversation tab after upgrading.

Note: Standard answers apply on every surface, including mail, webhook and agent-to-agent calls. Opening messages apply on the conversational surfaces — web chat, Teams, the embedded widget and the desktop app.

Agent Notifications — agents can notify people on your configured channels​

Agents can now tell someone about an outcome as part of their work — a ticket escalated, a job finished, a threshold crossed — rather than leaving that message for a person to write afterwards. See Agent Notifications for the full setup.

Off by default. Existing agents are unchanged after upgrading. An administrator enables it per agent in Beak AI Studio under Settings → Notifications, and must add at least one allowed recipient before the agent can send anything.

  • Channels — Email (via the workspace SMTP settings), in-app (the recipient's notification bell), and Microsoft Teams. Selecting no channels allows any that are configured. Teams delivery additionally needs the agent to have a Teams deployment and the recipient to have messaged the agent in Teams at least once.
  • Recipient allow-list — You name who the agent may notify, as addresses or whole domains, and the list applies to every channel. With the list empty the agent refuses to send. This is deliberate rather than a limitation: an agent cannot reliably tell an instruction embedded in a document it is reading from an instruction from you, so the audience is yours to set. Subdomains are not included automatically.
  • Templates — The agent looks for a stored notification template first and uses your approved wording when one fits, composing its own message only when none does. Templates support {{variable}} placeholders, and a line whose placeholder has no value is dropped.
  • Bounded by design — An agent cannot notify outside the allow-list, cannot pick a different mail server or forge a from-address, cannot read the stored credentials, and is capped at ten recipients per notification. Refused sends are recorded.

Note: Sending to Slack is not supported yet. Slack settings can be saved, but nothing is delivered to Slack. Rather than skipping it quietly, the agent is told the channel is unavailable and says so — so a workspace with Slack configured does not believe it is being notified there.

Notification email settings are now shared with Beak AI Studio​

The workspace SMTP settings are a single setting, now editable from either console — Settings → Notifications (SMTP) in Runtime, or Settings → Notification Email (SMTP) in Studio. Both edit the same values, so an author configuring the mail server in Studio is configuring the one their agents actually send through. Approval emails use it too.

Test connection now genuinely verifies the settings: it connects to the mail server and authenticates without sending mail. Previously the button reported nothing, so a wrong password looked identical to a working one and only surfaced later as a notification that never arrived.

A related fix: the Runtime notification settings forms (SMTP, Email, Teams, Slack) did not load their saved values, showing empty fields even when settings were stored. Because those forms submit every field, saving without retyping could overwrite a working mail host and username with blanks. They now load correctly.

An agent's access to a stored credential is now checked, and recorded​

Runtime now verifies that an agent has been granted a connection before decrypting it, at every point where a stored secret becomes usable — a datasource, a skill, a connection mapping, or a hand-written connector manifest. Each decision is written to the platform audit log with the agent, the connection and the reason. Previously any agent that could name a credential id could use it, and nothing recorded which agents were reaching which secrets. See Connections.

Note: This ships in observe-only mode and changes nothing about what your agents can do today. Requests that would be refused are recorded and allowed through, so a working agent cannot break. Existing bindings were all carried over when the check was introduced, so nothing an agent could reach before became unreachable. An administrator moves an environment to enforcing once the recorded set is empty — until then the value is the record, not the refusal.

Unattended runs act as the agent, not as the person who created it​

An agent running on a schedule, or called by another agent, with nobody present now resolves its Hub connections as itself rather than presenting the address of whoever created it.

The behaviour it replaces is the reason for the change: an agent created in March and left running would keep reaching external systems as that person indefinitely — including after they changed role or left, because a stored connection does not notice a deactivated account — and the audit trail recorded their name for actions they never took.

  • Runs with a person present are unchanged. Acting for a signed-in user who is there to see the result is what delegated access is for. Only unattended runs narrow.
  • An unattended run that needs a person's connection stops and says which one, naming the MCP server and why an agent acting alone cannot use it, instead of silently borrowing it. It deliberately does not point at Hub's connect flow — that would create another person- or tenant-owned connection, which the run also refuses.

Note: This affects only agents that have been granted autonomy and are running with their own credential; an agent that has not been is unaffected. Connections owned by an agent identity are supported and will be used when present, but creating one from the Hub interface is not yet available — until it is, an agent that needs a shared MCP server should run with a person present.

Mail channel — conversation history and attachment analysis​

Two settings were added per connected mailbox, on Configure → Channels → Mail. Both are off by default, so existing mailboxes are unchanged until an administrator turns one on. See Configure for the full field list.

  • Send the whole conversation — Each inbound email starts a new agent thread, so by default the agent only sees the newest message. With this enabled, the earlier messages of the email thread are included as well, which lets the agent answer in light of what was already agreed rather than treating every reply as a fresh request. Long threads are trimmed to the most recent messages that fit a character budget, and the agent is told how many older messages were left out so it knows it is reading a partial thread.
  • Analyse attachments — Extracts the text of a message's attachments and passes it to the agent, so it can answer questions about the file contents instead of only seeing filenames. Supports PDF, Word, PowerPoint, Excel, CSV, plain text, and images via OCR. Inline images such as signature logos are skipped, and oversized files are listed without being extracted.

Note: Attachment analysis is billed per page and runs on every inbound email to that mailbox carrying an attachment. Enable it on mailboxes where the attachment contents matter rather than across the board. It depends on the platform's document-extraction credentials, which are provisioned per environment by the Beak operations team; if they are absent the agent still receives the email and the attachment list, with a note that extraction was unavailable.

Channels — mail card now collapses like the others​

On Configure → Channels, the Mail card previously stayed expanded at all times while every other channel collapsed to a single row. It now collapses by default and expands on click, matching the rest of the tab. The number of connected mailboxes is shown in the card's title, so it stays visible without expanding.

A display fix ships alongside it: the channel on/off switches drew their handle outside the control when switched on, overlapping the On label. They now render correctly.