Use case · Engineering

Release trains that leave on time

Hedy shepherds the weekly release: merge deadlines chased, checklists confirmed, notices drafted — with every outward step waiting on a human approval. Scheduled jobs must name their delivery target explicitly.

Hedy runs release management as one private AI employee, not another Slack seat. It tracks cut-off deadlines and checklist items, holds all outbound release notes and customer notices behind L0/L1/L2 approval, and writes every shipped result into a ledger. Cron reminders declare an explicit target channel—never "last channel used." Self-hosted on your own Docker/K8s or air-gapped infra, with append-only audit and deny-by-default writes.

Last updated: 20 July 2026

How Hedy runs it

01

Owns the calendar

Knows the train schedule and merge cutoffs; reminds owners before the deadline, not after.

02

Checklist discipline

Walks the release checklist and reports gaps to the release owner.

03

Gated announcements

Release notices to public channels queue as approval cards. Approve or deny in one tap.

04

Recorded outcome

Ship or slip, the result is logged with reasons in the activity ledger.

Governed by design

  • Outward messages are L1 actions — human approval required
  • Scheduled jobs name their delivery target explicitly; no implicit sends
  • Missed cron runs alert the watchdog — silence is never success

In depth

Release management is coordination work that spans deadlines, checklists, approvals, and record-keeping. A cloud AI assistant that lives in Slack can remind you a cut-off is near, but it does not own the release. Hedy does. It is one AI employee running on your own infrastructure that watches the freeze window, walks the release checklist, and knows which steps are still open before a build ships. The point of hedy.one is that one Hedy carries the whole release loop instead of adding another seat to a channel.

Outbound communication is where releases go wrong, so Hedy treats it as a governed write. Drafting an external release note, a status-page update, or a customer notice is a write action, and writes are deny-by-default on a whitelist. Anything customer-facing routes through tiered approval—L0 auto, L1 single reviewer, L2 dual sign-off—before it leaves. Hedy can prepare the notice and stage it, but a human clears the gate. The limit lives in config and code, not in a prompt, so it holds even when the model is confident.

Every shipped release lands in a ledger. Version, checklist state, who approved the notice, when it went out, and the linked evidence are written to an append-only audit log with no update or delete path. When Hedy answers a question about a past release, the evidence gate requires it to quote the source verbatim rather than paraphrase from memory, and retrieval is scoped by the asker's ACL—so a report reflects what that person is allowed to see.

Cron is where automation quietly misfires, so Hedy makes the target explicit. A scheduled cut-off reminder or checklist nudge must name its destination channel in the job definition; there is no implicit last-channel fallback that can leak a reminder to the wrong audience. Hedy speaks Feishu/Lark as a first-class channel alongside Slack, uses your own model keys (including local vLLM or Ollama), deploys in about 30 minutes via compose, and ships no sub-processors—the release history stays on your infrastructure.

Questions

Can an AI employee send our release notes to customers automatically?
Only through approval. Hedy drafts release notes and customer notices, but any outbound message is a write action, and writes are deny-by-default on a whitelist. Customer-facing notices route through tiered approval (L0/L1/L2) before they send. Hedy stages the message; a human clears the gate. The rule lives in config and code, not in the prompt.
How does Hedy avoid sending a release reminder to the wrong channel?
Every cron job must declare its target explicitly. A cut-off reminder or checklist nudge names its destination channel in the job definition, with no implicit last-channel fallback. This removes the most common source of misdelivered scheduled messages. Hedy supports both Feishu/Lark and Slack as delivery targets.
Where does the record of each release live?
In an append-only ledger on your own infrastructure. Hedy writes version, checklist state, approver, send time, and linked evidence to an audit log with no update or delete path. When it answers questions about past releases, the evidence gate requires verbatim citation of the source, and retrieval is scoped by the asker's ACL.
Is Hedy self-hosted, and can we run it air-gapped?
Yes. Hedy is a private AI employee deployed on your own Docker or Kubernetes, including air-gapped setups. It uses your own model keys, including local vLLM or Ollama, so no data leaves your environment. There are no sub-processors, licensing is offline via Ed25519, and a compose deploy takes about 30 minutes.

Related

hedy.one

See it on your own infrastructure.

Book a demo