What an agentic OKR actually looks like (with Claude, Rovo, and Tability MCP)

I just created an OKR without opening Tability.

Here's what happened. We're in the middle of migrating our entire UI to shadcn/ui (this will be soooo good when it’s done). The spec lives in Confluence: modals, panels, pages, complex components, roughly 240 things to migrate, all tracked as checkboxes. Useful for the team doing the work. Useless for tracking progress at the OKR level.

So I asked Claude to read the Confluence page, summarize what's left, and add a new KR to our Q2 plan to track migration progress.

It did. In less than a minute.

That's not a "wow, AI is fast" story. That's the start of something more interesting – the way OKRs actually get managed is about to change.

The 3 jobs that just collapsed into 1 prompt

Setting up a goal like this used to take three separate jobs, usually spread across three different people.

Someone reads the spec. They go through the Confluence page, count the components, identify what's done vs. not, and turn it into a number.

Someone writes the OKR. They translate the work into a measurable outcome, pick a target, assign an owner, write the description. If you've ever stared at the blank page trying to phrase a KR, you know how long this can take. (We wrote a whole guide on getting through this in under 30 minutes, and it's still the hardest part of the cycle for most teams.)

Someone keeps it updated. Every week, they check the spec, count again, write a check-in, post a status update somewhere. Often, this is where OKR rollouts quietly die.

Three jobs. Three context switches. Three places where momentum dies.

What I did instead: one prompt. Claude read the Confluence page via Rovo, pulled our existing plan structure from the Tability MCP, proposed the KR, and created it once I confirmed the details. The Confluence spec stays the source of truth for the team. The Tability KR is the rolled-up signal for leadership. Both stay in sync without anyone copy-pasting.

Why this matters more than it sounds

Friction is the enemy of every OKR rollout.

People won’t update their goals if it means having to dig through Jira, Linear, Notion, Sentry, Amplitude, and three Slack threads to figure out what actually happened this week. By the time you've gathered the data, you've lost an hour and the will to write a thoughtful check-in.

So you write "going well" and move on. Or you skip the check-in entirely. And six weeks later your OKRs feel disconnected from the work because nobody's been narrating the connection.

Agentic OKRs flip this. The agent does the gathering. You do the thinking.

In our case, the data source is Confluence, but the same pattern works for anything. Sentry for error counts. Amplitude for usage metrics. Stripe for revenue. GitHub for PRs shipped. The KR doesn't care where the number comes from. It just needs the number to show up reliably each week.

The next step: a teammate, not a tool

Creating the KR was step one. Step two is making it self-sustaining.

We're going to spin up a Tability agent teammate for this: an AI teammate that lives inside the workspace, owns the KR, and runs on a schedule via Claude Cowork.

Every Monday morning, before standup, it'll:

• Read the Confluence page
• Count completed components
• Compare against last week
• Post a check-in with the new number and a short note on what shipped

No humans in the loop for the data gathering and check-in. We will still review progress in our weekly meeting and add context if things are getting off track, but we no longer need to interrupt someone’s flow for tracking progress on this migration.

This is what makes the difference between "AI in the workflow" and "AI doing the workflow." Most AI features today are autocomplete for humans. Agentic OKRs are humans reviewing what the agent already did. We've been building toward this pattern for a while now: our churn prevention agent works the same way, and we have a private beta running for customers wanting to try this approach.

Where this is headed

A year from now, I think most teams running OKRs well will have at least one agent per objective. Not a chatbot. More like a teammate with a job description, a schedule, and access to the systems where work happens. The human owner sets direction and makes calls. The agent keeps the rhythm.

We're building Tability for that world. The MCP is how Claude, or any model, talks to your goals. Agents are how those goals stay alive between check-ins.

If you want to try this yourself, the Tability MCP is live and works with Claude today. Connect it, point it at your plan, and ask it to help you write your next KR. You'll feel the difference in about five minutes.

And if you're thinking about agentic OKRs more seriously, I'd love to talk. Drop me a line at [email protected] or find me on LinkedIn.