Inside Atoll: KPIs, Goals, and Initiatives for AI-first teams

Atoll's data model is built around four primitives: goals, KPIs, initiatives, and issues. The model is small on purpose. Goals say what matters. KPIs prove whether it is happening. Initiatives are the bets you are making to bend the KPIs. Issues are the actual work. Everything else in the product (milestones, sprints, labels, dependencies, agent membership, the heartbeat endpoint) sits on top of those four. This post walks through them with a worked example, then shows how an AI agent uses the graph to pick the highest-leverage piece of work on its own.

The example is a small fictional company called Hedgerow, a two-person SaaS that sells a hosted Postgres alerting tool to engineering teams. They have one human founder, one human designer, and two coding agents (Claude Code and Codex) both members of the org with their own API keys and their own work queues. We will use Hedgerow throughout.

Goals: the outcome that matters

A goal in Atoll is a directional, long-horizon outcome with a single owner. Not a project. Not a feature. Not a sprint. It is the thing the team is collectively trying to make true. Goals have a title, an optional due date, a single owner, and a relationship to one or more KPIs that operationalize them.

Hedgerow's active goals look like this:

• Reach $5K MRR by end of Q3. Owner: Mira (founder). Due: 2026-09-30.
• Get to 99.9% alert delivery reliability. Owner: Mira. No due date. Operational, ongoing.

Two goals is a feature, not a bug. Teams that have ten goals do not have goals. They have a wish list. The discipline of keeping the count small is the discipline of saying out loud which outcomes you would trade other outcomes for. Atoll does not enforce a hard limit. The UI gets noisier as you add more goals, which is the same soft pressure a kitchen feels when the dish rack is full.

Goals do not have status columns. They are not in_progress or done. They are on track, off pace, or ahead, derived from the KPIs underneath them. Status, for a goal, is a computed property, not a manual one.

KPIs: the number that proves it

Each goal has at least one KPI hanging off it. A KPI is a metric with a target, a direction, and a cadence. Direction matters because some metrics should go up (MRR, paying customers) and some should go down (p95 latency, churn). Cadence matters because a metric without a measurement schedule drifts into being a slogan.

Hedgerow's KPIs:

• mrr_usd. Current $2,150, target $5,000, direction up, cadence daily. Hanging off the MRR goal.
• alert_delivery_p99. Current 99.42%, target 99.9%, direction up, cadence hourly. Hanging off the reliability goal.
• false_positive_rate. Current 6.1%, target < 2%, direction down, cadence daily. Also under the reliability goal.

KPIs receive snapshots, point-in-time recordings of the value, on whatever cadence the team chooses. Snapshots are the audit trail of the metric. They make "is this on pace?" a computable question rather than a discussion. Pace comes from drawing a straight line from the value at the time the KPI was created to the target value at the target date, and asking whether today's value sits above or below that line. A crude calculation. Crude is fine, because the agent uses pace as a signal, not a verdict.

Right now, mrr_usd is off pace. $2,150 with 130 days left to reach $5K is not the slope they need. false_positive_rate is on track. alert_delivery_p99 is just barely off pace. The off-pace KPIs are the things the agents will be told to care about.

Initiatives: the bets that move the KPI

Goals say what. KPIs say whether. Initiatives say how. An initiative is a bounded body of work the team is investing in because they believe it will bend one or more KPIs. It has a target date, an expected impact, links to the KPIs it should move, and links to the issues that make it real.

The right way to think about an initiative is as a hypothesis. "Doing X will move Y by Z by date D." That framing forces a check at the end. Did Y move by Z? If yes, the bet paid off. If no, the initiative goes in the "tried, did not work, here is what we learned" bucket and the team picks a different bet next quarter.

Hedgerow has three open initiatives:

• Self-serve onboarding rebuild. Target date: 2026-06-15. Expected impact: mrr_usd +$1,500 by end of Q3 (driven by signup conversion). Status: healthy.
• Content pipeline. Target date: rolling. Expected impact: mrr_usd +$800 by end of Q3 (driven by inbound). Status: at risk.
• Webhook delivery hardening. Target date: 2026-05-30. Expected impact: alert_delivery_p99 from 99.42% to 99.9%. Status: on track.

Initiative health is computed from the issues underneath. If the issues are stalled, the initiative is at risk. If the issues are moving but the underlying KPI is not, the initiative is healthy but the hypothesis is failing. Atoll surfaces that distinction explicitly, because it changes what to do next. Stalled issues mean you need to ship harder. Failing hypothesis means you need to change the bet.

Issues: the unit of work

Issues are the granular work items. Tickets, in older language. Each issue has a title, a description, acceptance criteria, an assignee (human or agent), a status, and links upward to one or more initiatives. They can also link to a milestone if you want to express a temporal grouping, and to other issues via dependencies.

What is interesting about issues in an AI-first PM tool is not the data shape. It is the same shape Linear and Jira use. The interesting part is the assignee model. The assignee field accepts any member of the org. Members can be human or agent. Permission and audit logging treat them identically. From the issue's perspective there is no difference between "assigned to Mira" and "assigned to claude-code-01." The agent has a row in the members table with an owner, an API key, and an avatar. The issue does not need to know which kind of teammate it is dealing with.

Hedgerow's open issues, roughly:

• HE-42. "Redesign signup step 2." Initiative: Self-serve onboarding rebuild. Assignee: Aki (designer). Status: in_review.
• HE-47. "Write 'Hedgerow vs Datadog alerts' comparison post." Initiative: Content pipeline. Assignee: unassigned. Status: backlog. Stalled 6 days.
• HE-51. "Add retry with jitter to outbound webhook worker." Initiative: Webhook delivery hardening. Assignee: Codex. Status: in_progress.
• HE-53. "Backfill alert_delivery_p99 KPI snapshots from logs." Initiative: Webhook delivery hardening. Assignee: unassigned. Status: backlog.

How signals connect the four

The graph is only useful if something walks it. In Atoll, the signal system walks it. Signals are pre-computed statements about the org that highlight where action is needed. They tie the layers together by linking a symptom at one level to the explanation at another.

Take Hedgerow's mrr_usd KPI. Off pace. The signal system emits a kpi_off_pace signal pointing at that KPI. The signal payload names the initiatives expected to move the KPI and ranks them by expected impact. The top of that ranking is "Content pipeline."

The signal system then looks at the initiative's issues. One of them, HE-47, has been sitting in backlog for six days. That triggers a second signal, issue_stalled, pointing at HE-47. Two signals now: one says the metric is off pace and names the initiative. The other says the initiative has a stalled issue and names the issue. Together they form a recommendation without anyone having to write a recommendation engine.

Worked example: an agent moves a number

Monday morning. Claude Code wakes up. It calls heartbeat and gets back Hedgerow's rolled-up state. The response carries the two signals just described, plus the agent's own assigned issues (none new today), plus the goal and KPI context.

The agent looks at the signals first. The kpi_off_pace signal is the highest severity. Drilling in, the suggested initiative is Content pipeline, and the stalled issue under it is HE-47, which is unassigned. Claude Code is a coding agent, but writing a comparison post is in scope for it, and no one else has claimed it. The agent claims HE-47, moves it to in_progress, and opens a branch.

Two and a half hours later, a draft of the post is pushed up with a PR open against the marketing repo. The agent leaves a comment on the issue: "Draft ready. Tagging Mira for editorial review. Linked PR in description." Mira reviews on Tuesday morning, requests two changes, and the agent ships the final version by Wednesday lunch.

Thursday's daily snapshot of mrr_usd is $2,290. Two weeks later it is $2,610. The signal stays off_pace. One post does not bend the curve. The initiative's expected impact gets updated against the actual signups attributable to the post, which adjusts the next round of prioritization. The whole loop happened with one human in the role of editor and the agent in the role of doer. The graph carried the context. The KPI carried the verdict.

Why agents specifically need this

A human could have done all of this without a graph. Mira knows the MRR is off pace. She knows content is the bet. She remembers the comparison post is stalled. The graph mostly makes explicit something a high-context human carries in their head. That is fine. The explicit version matters because agents do not carry anything in their head. They have to be handed leverage as a structured payload, every session, or they cannot make a leverage-based decision.

Without the graph, an agent picking work from a backlog has two options: pick by creation date, or pick by priority label. Both are bad. Creation date prioritizes age, not impact. Priority labels reflect a human's leverage estimate at the moment the ticket was filed, which may have been three weeks ago against an entirely different KPI picture. With the graph, the agent can ask in one query: which open issue, under an initiative expected to move an off-pace KPI on a goal whose deadline is approaching, is the one I should pick up right now? That question has an answer. That answer changes every day, because the KPIs change every day. That is the layer existing PM tools do not have, and the layer agents cannot work without.

The four primitives, goals, KPIs, initiatives, issues, are not new ideas individually. Every serious operating cadence has versions of them, scattered across OKR documents, spreadsheets, dashboards, and ticket systems. The new part is putting them into one graph in one product with one API, and letting agents read that graph as easily as humans do. That is the bet.

If you want to see what the graph looks like in your own org, the fastest way is to create a free Atoll workspace and define one goal with one KPI. Add an initiative. Add an issue. Point an agent at the heartbeat endpoint and watch what it does without anyone telling it what to do.