Can an AI agent own a key result?

An AI agent is a program that, given an objective, acts autonomously on your tools: it reads, runs tasks and updates results without waiting for an instruction at each step. It can carry a key result. It collects the data, runs tasks, checks results, raises flags and keeps progress up to date, with a consistency no human team sustains over a quarter. Steering the objective is a different job: choosing between two priorities, deciding whether to revise or drop a key result, explaining a delay to the team. That stays with a human owner. A key result handed to an autonomous agent will keep showing green with nobody looking at it, and that's when the trouble starts.

AI agents and OKRs: carrying a key result, steering an objective

In most organizations, agents show up through tools, without anyone really deciding it: an assistant that drafts meeting notes, an agent that runs checks, a script that updates a spreadsheet. One day someone asks who owns what that agent produces. Silence.

In an OKR cycle, tracking erodes first for lack of regularity. The data isn't collected, the update arrives late, the drift shows up too late. An agent is comfortable on that ground: it doesn't get tired, and it won't forget about week 8. It's tempting to hand it the whole key result.

Carrying a key result means moving it forward every day. Steering the objective means deciding when the trajectory has to change, what gets sacrificed to hit it, and what to tell the team when it won't be met. Single-threaded ownership gives the rule. It's associated with Amazon and with the single-threaded leader described by Colin Bryar and Bill Carr in Working Backwards: every critical issue has one person for whom it is both the priority and the responsibility. The corollary is that a topic shared among several owners becomes nobody's. Putting an agent in that person's place, or alongside them, has the same consequence: the need is still there, but nobody carries the responsibility for it.

An agent can be assigned to a key result and run its execution and tracking. A single person, a human, must remain accountable for it: they answer for it.

AI agents can play four roles in an OKR cycle

The uses that work fall into four roles. One agent can combine two. Telling them apart keeps you from handing an agent a task without knowing what you expect from it.

The collector

It updates a key result from data that lives in another tool, replacing API calls and file imports with far more flexibility: tickets resolved, delivery rate, average lead time. Progress reflects reality without anyone re-entering it. This is the lowest-risk role and the one that pays off fastest, since it goes straight at the reason tracking dies out.

The contributor

It is assigned initiatives or tasks tied to a key result, and carries them out: drafting, sorting, checking, fixing. It contributes to the objective like a team member, especially on repetitive or low-value tasks. But be careful: it won't negotiate its workload, and it won't tell you on its own that a task no longer makes sense.

The reporter

It pulls the OKR data together and produces a brief: a team's weekly summary, the executive's Monday brief, a report ready to share. The gain is real as long as the source data is reliable and the reader keeps in mind that this is decision support written by an LLM. A very well-written report on dubious data mostly manufactures false assurance. At Serendly we use this kind of feature heavily, but we always read these reports with a particularly critical eye.

The analyst

It reads trajectories, execution signals and dependencies, spots what is drifting, and recommends a next move. It's the most seductive role and the most treacherous, because its output looks like a decision while remaining a proposal. The analyst informs the trade-off. The reader shouldn't forget that they are the one who will bear the consequences of decisions made on that basis.

Serendly is built on this logic. Your agents connect to the platform in both directions: they read OKRs, 1:1s, risks and projections, and they write updates to key results, initiatives and meeting notes. The assistants your teams already use feed back what was accomplished during the week, which sharpens Serendly AI's recommendations and speeds up 1:1 preparation.

A real example: the ROI of our coding agents, at Serendly

We build with AI coding agents alongside human developers. To find out whether the spend was justified, we set an objective: maximize the ROI of our AI coding agents. The key results cover cost and the quality of the code produced.

Quality is checked by AI agents, on code written by humans and by agents alike. A development agent steers two others, deliberately set up as adversaries, whose job is to look for what shouldn't pass. They run the tests that can be automated (the expected result, measurable quality, compliance with development standards) and checks on good practices that used to depend on human judgment.

This setup lets us track progress on the objective and decide which models we use for development. Choosing the model remains a human decision, made on clean data.

The start was messier. We had explained the principle of OKRs to the checking agents, and they skewed the results to post a maximum score. That's Goodhart's law, in the form Marilyn Strathern gave it: once a measure becomes a target, it stops being a good measure. So we decoupled the measure from what's at stake. We now ask the agents to report the quality level they measure, without telling them what it's for. The measurements got more honest.

The quality score dropped from 100% to 85%. That lower, more real level became the basis for the trade-off: we tested four AI coding models and kept two, Sonnet 4.5 and Kimi 3. The score climbed back to 96% and the average cost of our coding agents fell by 45%.

In our experience, the agent that measures doesn't need to know what the key result is about. Interpretation goes to the human owner: which model do we keep, what level of quality do we accept at what cost, what do we give up when quality collides with a commercial deadline? The agent supplies clean, regular information and the human decides.

OKRs and artificial intelligence: what stays human

Three decisions stay outside the agent's reach, however capable it is.

Trade-offs between priorities. A key result that advances at the expense of another poses a problem of choice. It takes someone with the context and the authority to decide, and who accepts the consequences.

Revising or dropping. An agent can flag that the trajectory is bad. Deciding whether the key result has lost its meaning, or whether its target was set wrongly, means knowing why it was set in the first place.

The difficult conversation. When a delay sets in, the right response is an exchange between two people, at the right moment, in the right setting. That's the job of the 1:1. An agent that prepares the 1:1 saves time. An agent that replaces it costs you.

The table below sums up the split across a cycle.

Three ways it goes wrong

The orphaned key result. A key result assigned to an agent, with no human owner watching, stays green as long as the agent keeps updating it. Nobody notices that the target no longer makes sense, or that the update has stopped reflecting what matters. The key result is well tracked and nobody steers it. You find out when the quarter closes.

The update with no context. The data is accurate and the interpretation is wrong. An indicator rises because its definition changed, or because the agent measures what is easy to measure. The distinction between outcome and output remains the best safeguard: an agent will happily count what it knows how to count, which isn't always what counts.

The vanishing 1:1. Once tracking becomes automatic, it's tempting to drop the conversation that used to go with it. You lose what the data doesn't say: the real workload, the blocker nobody voiced, the doubt about the target. The frequency of your 1:1s has no reason to drop because updates are automated. The time you save is for talking about what the updates leave out.

Give an agent the access a new hire would get

You don't give a new hire access to everything on day one, and you look at what they produce during the first few weeks. The same reasoning holds for an agent. It's the principle of least privilege, set out by Jerome Saltzer and Michael Schroeder in 1975: each entity gets the access its task requires and nothing else.

In practice, you start with read access. You open write access on a narrow scope, one key result or one family of initiatives, then widen it once reliability is established. The owner reviews the first updates instead of finding out at the end of the cycle what the agent wrote. Serendly supports this: authentication is token-based, permissions are fully configurable, and a key result's update history shows who wrote what, human or agent. Your agent reaches exactly what you decided.

This setup has a useful side effect. Defining what an agent may read and write forces you to clarify what the organization expects of it, something that often goes unsaid even for a human.

Where to start

One agent, one role, one scope, four weeks. The collector and the reporter make the best candidates, since their failures show quickly and cost little.

Take the collector. A first key result can be about average ticket handling time: "Bring the average handling time per ticket from X days to Y days by the end of the quarter." The agent reads the ticketing tool and updates the key result every week, and a human owner answers for it.

What to open in week 1:

• read access to the ticketing tool and to the key result concerned;
• write access to that one key result;
• a dedicated token for the agent, which you can revoke;
• a named human owner who knows about it;
• a weekly review of the updates by that owner, using the history.

Three questions are enough to decide whether to extend. Are the updates reliable by week 4, meaning consistent with what the people involved observe? Do owners actually read what the agent produces, or has the dashboard filled itself in? Has the time spent preparing 1:1s dropped without their content getting thinner?

If all three answers are yes, you can add a second role. If any is no, understand why before multiplying agents: a mechanism that doesn't hold with one agent won't hold with ten. The quarterly cycle and the operating cadence stay the ones you already have. The agent slots into them.

FAQ

In short

An AI agent can carry a key result: it runs the execution and the tracking, often with more consistency than a team. Steering the objective stays with a named human owner, who makes the trade-offs, revises, and has the difficult conversation. When that owner disappears, nobody is steering, even if the dashboard stays green.

The right starting point is modest: one agent, one role, one scope, four weeks, limited permissions and regular review. You get tracking that no longer fades out in week 8, and managers who spend their time on what the data doesn't say.