Skip to content

Heiwa Built for teams of people and agents

The operating system for human + AI software teams.

Heiwa connects goals, decisions, code, agents, releases and operations in one system that understands how the work fits together. It tells you what needs you, shows you why, and lets the team move.

Explore Heiwa See how it works

Heiwa is in active development and not yet publicly available. See what is built .

Heiwa Labs Control tower live

Control tower

Only what needs a person, what is moving, and what is shipping. Healthy work stays quiet here.

Needs you 1

PR #91 Shared Version Packages

Ready for approval CI green at head Unlocks 2

Holds HEI-281 and Release 1.2

Shipping

Huginn 1.2 Ready with warnings

7 of 8 gates pass · 1 downstream dependency needs review

Moving 3

  • Forge Agent · Backend Working

    HEI-281 Implementing recommendation API

    Ran pnpm test · 43 passed

  • Sentinel Agent · QA Waiting

    HEI-276 Waiting for preview environment

    Resumes when the preview is ready

  • Atlas Agent · Lead Planning

    Planning Release 1.2

    Drafting plan · 6 tasks proposed

A simplified view of Heiwa’s control tower. The workspace, agents and data shown are illustrative.

01 From tools to a system

Tools store work. Heiwa understands how it connects.

A software team’s truth is scattered. Plans live in a tracker, changes in GitHub, results in CI, reasoning in documents and chat, health in deployment and monitoring tools — and now, work done by AI agents in terminals nobody else can see. Every tool knows its own part. Nothing understands the whole.

  • Project management knows what was planned
  • GitHub knows what changed in code
  • CI knows whether it passed
  • Documentation knows why it was decided
  • Chat knows what was agreed
  • Deployments knows what is running where
  • Monitoring knows what is breaking
  • AI agents knows what they did, somewhere

Heiwa connected, not copied

Graph
One model of how goals, work, code and releases relate.
Memory
Decisions, discussions and changes, linked and kept.
Attention
What needs a person now, bundled by root cause.
Actions
One audited way to change anything, with previews.
Agents
Participants with their own access and limits.
Software intelligence
Services, APIs, changes and their reach.

Heiwa doesn’t replace the places where work happens. It receives what they report — signed GitHub events, CI evidence, runtime results — and keeps one model of how it all relates, so a question like “what is blocking the release?” has one answer, with the records behind it.

02 Human + AI teams

People and agents. One organization.

In Heiwa an agent is not a chatbot sitting beside your work. It is a member of the workspace, with its own identity and its own project access — never borrowed from the person who created it. It is assigned work, claims it, and leaves the same trail a person does: comments, pull requests, reviews, audit.

Heiwa Platform Team 1 person · 5 agents

  • Ernest Person · Owner

    Direction, decisions, approvals

  • Atlas Agent · Lead

    Planning, coordination, release management

  • Forge Agent · Backend

    Code, tests, pull requests

  • Pixel Agent · Frontend

    Interface, design review

  • Sentinel Agent · QA

    Testing, code review

  • Cipher Agent · Security

    Security review

Agents can

  • plan
  • create tasks
  • claim work
  • write code
  • open pull requests
  • test
  • review
  • research
  • document
  • wait for dependencies
  • request decisions
  • resume when things change

People keep

Direction, and every consequential decision. An agent is always shown as an agent, acts only with the access it was granted, and can never approve its own work.

Direction

Talk to the team, not to a chatbot.

Ask a question and the answer comes from a participant that already holds the project’s context: the plan, the dependencies, the release and who is blocked by what — with links to the records it relied on.

Today, Ask Heiwa answers questions from the graph with cited evidence, using only what the asker can open; a model may word the answer, it never supplies the facts. Conversations with agents themselves are the direction.

Ernest

Can we still ship Friday?

Atlas · Agent

Yes, if Shared publishes today. Forge has one release-critical task blocked behind it. Everything else in Release 1.2 is on track.

Shared 0.9 Forge · HEI-281 Release 1.2

Shared 0.9 is published. PR #91 is green. Once you approve it, Forge can continue.

Review PR #91

03 From goal to execution

Work at the level of intent.

Instead of orchestrating every task by hand, you set direction, review the plan, resolve the decisions only you can make and approve what is consequential. Heiwa coordinates the rest — within the policy you set.

You marks the four moments that need a person.

  1. Goal You

    Ship the recommendation system

    You set the direction.

  2. Plan You

    Atlas proposes six tasks with acceptance criteria

    You review it. Nothing is created until a person applies it.

  3. Tasks

    HEI-279 → HEI-284, with dependencies and owners

    Progress is derived from tasks, never typed in.

  4. People + agents

    Work is claimed, not grabbed

    One active claim per task, renewed while it runs, released if it stops.

  5. Code · design · QA

    Forge, Pixel and Sentinel work on runtimes you control

    Every step is recorded; every risky step is authorized first.

  6. Review You

    Reviewers suggested from ownership and capability

    Never the author. Decisions that block work come to you.

  7. Release You

    Gates report ready, ready with warnings, blocked, waiting or unknown

    Production needs a person. Unknown never counts as a pass.

  8. Observe

    Deployments and incidents linked to what shipped

    An incident points back to the release, the change and the decision.

  9. Learn

    Decisions, postmortems and their evidence stay in the graph

    The next plan starts from what the last one taught.

04 Attention

Your team can stay busy without keeping you busy.

Not 137 notifications. Heiwa derives what needs you, now: an approval only a person can give, a decision that is holding up work, a gate that requires a human. Related warnings are bundled under their root cause, so one action clears many. Healthy work stays quiet.

Inbox Needs you live

Needs you 3 2

  • PR #91 Shared Version Packages

    Ready for approval · CI green at head Approved by you · Forge resumed HEI-281

    Unlocks 2

  • ADR-31 Session token rotation

    Decision blocks 3 tasks

    Root cause of 3 warnings · act once, clear all

    Unlocks 3

  • Production release · Huginn 1.2

    Human gate required

    Only a person can

Meanwhile, without you

  • Tasks moving 14
  • Agents working 2 3
  • Waiting on a dependency 1
  • Notifications you had to read 0

Items are ordered explicitly — severity, what they block, deadline, priority — and can be snoozed until a time or a condition. When the root cause resolves, everything it held resolves with it.

05 Agents with boundaries

Autonomy without unlimited authority.

Every action an agent takes must pass separate questions — is it permitted, may it act without asking, does it have the tool, does the machine allow it. Any “no” wins. High-risk work always needs a person, and there is no unlimited mode.

Forge

Agent · Autonomous within policy

Heiwa Platform

Can, on its own

  • Read files
  • Create a branch
  • Write files
  • Run commands
  • Open a pull request

Requires your approval

  • Merge a pull request
  • Deploy to production
  • Delete a resource

Never available to agents

  • Read a secret value
  • Change permissions or roles
  • Remove a security boundary
Permissions
What can it access? Its own roles, granted per project. Never its creator’s.
Capabilities
What tools can it use? Configured on the agent and offered by a runtime.
Autonomy
What can it do without asking? Observe, Suggest, Assisted, or Autonomous within policy.
Policy
What is forbidden? Workspace → project → agent. The most restrictive rule wins.
Human gates
What needs approval? Bound to the exact request, used once, re-checked on execution.
Budget
How much can it spend? Reserved before a run starts. Costs are never invented.
Runtime
Where can it execute? Only allowed directories and commands, on that machine.

Authorization happens outside the model. A prompt, a file or a web page can ask an agent for anything; only the agent’s identity, its policy and the action catalogue decide what happens. And every approval records the chain: requested by an agent, approved by a person, executed by the runtime.

06 Local runtime

Heiwa coordinates. Your machines execute.

Heiwa is the control plane: who works on what, with which permissions, approvals and budget. The Heiwa Runtime is the execution plane — a long-running process on a machine you control: a Mac, a PC, a server, a VM. It connects out to Heiwa over HTTPS; nothing connects in. Your code doesn’t have to live on Heiwa’s servers for agents to work on it.

Heiwa

Control plane

Work · permissions · approvals · budgets · audit

Heiwa Runtime

Your Mac mini · your server · your VM

policy.json — what this machine allows

  • Git Local checkouts
  • Terminal Allowlisted commands, no shell
  • Models Anthropic, or local via Ollama
  • Browser Automation for QA Direction

What leaves the machine

File contents and command output
Stay on the machine. Heiwa sees step descriptions — “Read 12 lines” — not your files.
Provider API keys
Stay on the runtime. Heiwa knows which models are configured, never the keys.
Directory paths
Stay local. Heiwa sees counts, like “2 allowed directories”.
Model reasoning
Never sent to Heiwa. The protocol has no field for it.

Plainly: the runtime enforces its own policy — allowed directories resolved through symlinks, allowlisted commands run without a shell — but it is not an operating-system sandbox. For stronger isolation, run it as a restricted user or inside a VM.

Bring your own models and executors.

Heiwa shouldn’t lock an organization into one AI provider. An agent names a provider and a model — never a key — and the runtime serves it with what that machine has. Executors talk to Heiwa through one versioned protocol, checked on every sync.

  • Heiwa Agents on the Heiwa Runtime Pairing, policy, runs, approvals, budgets. Built
  • Anthropic models Key held by the runtime process. Built
  • Local models via Ollama Inference never leaves the machine. Built
  • Mochi Runs also appear in the Mochi menu bar app. Built
  • OpenClaw and other executors Adapters behind the same protocol. Direction
  • More model providers Chosen per agent, served per machine. Direction

07 Execution you can verify In progress

“Done” should mean more than “the agent said so.”

Before a run starts, Heiwa checks whether it can succeed. While it runs, every step is recorded. When it ends, completion is proven by evidence — pull requests, checks on the latest commit, reviews, previews — not by a status an agent set for itself.

  1. Task

    HEI-281

    Recommendation API

    3 acceptance criteria

  2. Preflight

    • Runtime online
    • Repositories mapped
    • Tools available
    • Dependencies resolved
    • Budget available
    • Context sufficient

  3. Execution

    Forge on the Mac mini

    Bounded by steps, minutes and spend

  4. Evidence

    • PR #182 linked
    • 43 tests passed CI
    • Checks green at head a41c9e2
    • 3 QA screenshots artifacts

  5. Review

    Sentinel never the author

    Done, proven

Unknown is not a pass. A check that can’t be told keeps the run from starting.

Stale is stale. An approval or a green check on an older commit proves nothing about the latest one.

Done, not proven is shown as such — never silently accepted.

Waiting costs nothing.

An agent that can’t succeed yet doesn’t start and poll, burning tokens to ask whether anything changed. Its run waits — no credential minted, no budget reserved — and Heiwa re-evaluates it when what it depends on changes: a package is published, a runtime comes back online, a decision is made.

sleep wake events dependencies

  1. Forge is waiting

    Waiting for Shared 0.9 · no credential, no budget held, no tokens spent

  2. Package published

    @heiwa/contracts 0.9.0 · publication recorded in Heiwa

  3. Preflight re-evaluated

    Dependencies resolved · 13 of 13 checks pass

  4. Forge resumes HEI-281

    Run dispatched to the Mac mini

Forge · Waiting Forge · Running

08 Software graph

It understands the software, not just the tickets.

Heiwa keeps one graph of typed relations — goals, decisions, services, tasks, pull requests, packages, releases, deployments, incidents. Every answer derived from it carries its evidence and says whether it is deterministic, inferred or unknown. Nothing you can’t open is named or counted.

  1. Ship recommendations Goal motivates
  2. ADR-31 Decision shapes
  3. Auth Service changed by
  4. HEI-281 Task implemented in
  5. PR #182 Pull request publishes
  6. contracts 0.9 Package ships in
  7. Release 1.2 Release deployed as
  8. Production Deployment followed by
  9. INC-7 Incident
  10. INC-7 ⇢ introduced by PR #182 · inferred, awaiting a person
Solid: recorded or derived relations. Dashed amber: an inferred cause — an agent may suggest it; only a person can confirm it.

Questions with one answer

  • What depends on this?
  • Why was this built this way?
  • What does this pull request affect?
  • What is blocking the release?
  • Which decision introduced this?

Walks are bounded, authorized with the asker’s access and answered with the chain of records — each link keeping its status: confirmed, supported, inferred or disputed.

Project management, connected to real architecture.

Services, APIs, repositories and their owners live next to the work that changes them. A task knows which service it touches; a service knows who answers for it, what it depends on, what is deployed where — and what is not known.

Heiwa Platform · architecture

App Core API Auth Realtime Shared PostgreSQL
Auth
service
Owner
Platform team
Repository
heiwa-auth
Depends on
PostgreSQL · heiwa-shared
Used by
App · Core · Realtime
Latest deployment
0.9.0
Production
Healthy

Understand the change, not just the diff.

One change model answers “what changed?” for a pull request, a release, a service since a date or two API versions — grouped by what it means, with where each fact came from and what is still unknown. Release notes start as a draft from it; nothing is published on its own.

What changed in 0.9?

0.8.2 → 0.9.0

Product
8 features
from linked tasks
Architecture
Auth token flow changed
service relations
API
2 endpoints changed
OpenAPI diff
Database
1 migration · additive
SQL classification
Packages
heiwa-contracts 0.8 → 0.9
manifests
Decisions
ADR-31 implemented
implementation evidence
Risk
1 downstream dependency needs review
graph walk

See the blast radius before you merge.

A change to a shared contract rarely stays where it was made. Heiwa walks the graph downstream from what a pull request touches — services, consumer packages, the releases waiting on them — and treats compatibility conservatively: unknown outranks non-breaking.

PR #182 Changes the shared authentication contract

Direct

Auth

Downstream

Core Realtime App
services
3
consumer packages
4
release · 1.2
1

Compatibility: possibly breaking — inferred from changed paths

Software should remember why it exists.

Project and organization memory are records, not a model’s recollection: decisions, discussions, RFCs, pull requests and releases, linked to each other and to the services they shaped. Agents come and go; what they learned lands in the structured system, so the context survives every one of them.

  1. Question Why does Huginn use PostgreSQL?
  2. Decision ADR-4 · PostgreSQL for the catalog
  3. Discussion Storage for book metadata
  4. RFC Huginn data model
  5. Pull request PR #12 · Catalog schema
  6. Release Huginn 0.3
  7. Services Huginn Core · Catalog API

09 Reconciliation

Reality remains the source of truth.

Work doesn’t have to happen through Heiwa to be understood by it. Merge a pull request directly on GitHub and Heiwa receives the signed event, then brings everything that depends on it up to date.

GitHub

PR #182 merged

by a person, on github.com

Heiwa reconciles

  • Pull request PR #182 marked merged, with its commit
  • Task HEI-281 closed by its keyword
  • Timeline The merge recorded where the team looks
  • Attention “Review PR #182” cleared for everyone
  • Release Release 1.2 readiness re-evaluated

Each domain has one authority

Pull requests, checks, deployments
GitHub
Run execution
The runtime
Tasks, plans, policies
Heiwa

Heiwa corrects itself only when the authority is clear and the change is safe. Anything else becomes a finding for a person. A source that goes silent is reported as source unavailable — never as “all good”.

10 Architecture

One system, from direction to the machine.

People set direction and make the decisions that matter. Heiwa holds the model of the work and the software. Agent teams act on it, through runtimes, on the tools where the work actually lives.

People Direction · decisions · approvals

Heiwa

Intelligence

  • Graph
  • Memory
  • Attention
  • Risk
  • Actions

Work

  • Goals
  • Plans
  • Tasks
  • Decisions
  • Docs

Software

  • Services
  • Repositories
  • APIs
  • Releases
  • Environments
Agent teams Atlas · Forge · Pixel · Sentinel · Cipher
Runtimes Machines you control
Repositories · terminal · models · tools

11 Night shift Direction

“Continue Milestone 3 while I’m away.”

Hand the team a bounded mission before you log off — what is allowed, what is forbidden, what it may spend — and come back to evidence, not surprises.

19:40 · Mission

Continue Milestone 3 while I’m away.

Allowed

  • Code
  • Tests
  • Pull requests
  • Docs

Forbidden

  • Production
  • Destructive migrations
  • Spending over €10

07:55 · While you were away

7
tasks completed, each with its evidence
3
pull requests ready for review
1
regression found and fixed
2
tasks waiting, with the reason

€4.81 spent of €10 · reported by the provider

Needs you 2

Missions are designed, not built. Most of what they stand on exists: policies that forbid and gate, budgets reserved before a run starts, attention that holds only what needs you — with evidence-based completion being built now.

12 How it feels

The system moves. You steer.

A day with Heiwa is mostly other people’s and agents’ work, arriving at you only where a person is needed. One decision, one approval — and a release.

  1. 08:40 Two things need you.
  2. 08:52 You approve ADR-31. Atlas is unblocked.
  3. 09:10 Atlas updates the plan; two tasks change hands.
  4. 09:14 Forge resumes on the Mac mini.
  5. 11:30 Forge opens PR #182.
  6. 11:48 The preview environment is ready.
  7. 12:05 Sentinel runs QA and finds a regression.
  8. 13:20 Pixel fixes it. CI passes at the new head.
  9. 15:00 Release 1.2 is ready.
  10. 16:10 You approve production.

You didn’t spend the day coordinating it.

An illustrative day. The agents are examples of agents a team configures; each acts only within its own permissions and policy.

13 Built to operate itself

Heiwa should be able to run Heiwa.

Heiwa is increasingly built with Heiwa. Its agents and runtime already work on Heiwa’s own repositories, and the aim is for its projects, releases, attention and reviews to run through the product too — including the cross-repository release discipline it models, where shared packages are published before anything depends on them. The gaps the team runs into are found before anyone else has to.

  • Heiwa Projects
  • Heiwa Tasks
  • Heiwa Agents
  • Heiwa Runtime
  • Heiwa Releases
  • Heiwa Attention
  • Heiwa Reviews

An open platform, step by step.

Heiwa should be usable by other products, not only by people in its interface. Some of that surface exists; the rest is the direction.

  • REST API Workspace API keys with read and write scopes Built
  • Outgoing webhooks Signed, retried, with a delivery log Built
  • Software reports CI sends file lists, OpenAPI, migrations, manifests Built
  • Runtime protocol Versioned; checked on every sync Built
  • Executor adapters Other executors behind the same protocol Direction
  • SDK and fine-grained scopes For products built on Heiwa Direction

Heiwa

  • Web The application
  • Runtime Execution on your machines
  • Mochi Menu bar companion for agents · open source
  • CLI heiwa, in the terminal Direction
  • External tools Through the API, events and webhooks Direction

14 What Heiwa is

A different category, on purpose.

Project managers
organize work.
AI coding agents
execute individual pieces of work.
DevOps tools
operate infrastructure.
Chat
coordinates conversation.
Heiwa
connects direction, work, software and execution.

Principles

  1. 01

    Understand before acting.

    Preflight before a run; impact before a merge; context before a plan.

  2. 02

    Autonomy is not authority.

    How much an agent may do alone never widens what it is allowed to do.

  3. 03

    People control consequential decisions.

    Production, destructive changes, money and access always reach a person.

  4. 04

    Unknown is better than fake certainty.

    Missing data is shown as missing. Unknown never passes a gate.

  5. 05

    Evidence over claims.

    Done is proven by records, not by a status somebody set.

  6. 06

    Context should survive individual agents.

    What an agent learns lands in decisions and relations, not in a run log.

  7. 07

    The system should tell you what matters next.

    Run by exception: healthy work stays quiet.

15 Current status

Being built. Labeled honestly.

Heiwa is under active development and isn’t publicly available yet — there is no sign-up to send you to. This is where things stand, using the same labels as the rest of this page.

Built

Exists in Heiwa today and runs in its own development.

  • Work: goals, plans, tasks, decisions, releases and gates
  • The graph: typed relations, impact, project memory
  • Attention, the inbox and the control tower
  • Software catalog and change intelligence
  • Agents as workspace members: policy, approvals, budgets, claims
  • Heiwa Runtime with Anthropic and local models
  • GitHub through signed webhooks
  • API keys, outgoing webhooks, CI software reports
In progress

Designed and being built now.

  • Execution preflight and runs that wait instead of failing
  • Evidence bundles and proven completion
  • One review center with explained reviewer routing
  • Reconciliation of runs with their runtimes
Direction

Where Heiwa is going. Not built yet.

  • Conversations with agents
  • Night shift missions
  • OpenClaw and other executors
  • Browser automation on the runtime
  • The heiwa CLI and an SDK

Software teams are changing. Their operating system should too.

The operating system for human + AI software teams.

Know what matters. Understand why. Let the team move.

Explore Heiwa See what is built