Drafting OKRs from Jira, GitHub and your HR system with AI

Ask a general-purpose chatbot to “write OKRs for my engineering team” and you’ll get something that sounds right and fits no team in particular: “Improve code quality”, “Increase velocity by 20%”. The model has no idea what your team is building, who’s on it, or what last quarter looked like. OKR.ai fixes that by reading the tools where that information already lives, over the Model Context Protocol, before it drafts a word.

#Why generic AI OKRs fall flat

Good OKRs are specific. They name the product area, the customer segment and the metric, and they start from a real baseline. A language model can write in that shape, but without your data it has to invent the specifics, or leave them vague. The output looks like an OKR and can’t be acted on.

The information a good first draft needs already exists, scattered across your tools:

• Project trackers (Jira, Linear, Asana, monday.com) know what each team is building: epics, milestones and their status.
• Engineering tools (GitHub, GitLab, Sentry) know about delivery and quality.
• Incident tools (PagerDuty, Opsgenie, ServiceNow) know about reliability.
• HR systems (Workday, BambooHR, HiBob, Rippling, Personio, Deel) know who’s on each team and who reports to whom.
• Docs (Notion, Confluence, Google Drive, a handbook site) often hold the strategy itself.

#What is the Model Context Protocol?

The Model Context Protocol (MCP) is an open standard, introduced by Anthropic in late 2024, for connecting AI applications to external tools and data. A tool exposes an MCP server; an AI application connects to it as a client and can read its resources or call its tools. Many vendors now publish hosted MCP servers, so connecting is often just a URL and a sign-in.

For an OKR tool, MCP means one well-defined way to read context from dozens of systems, instead of a custom integration for each one.

#How OKR.ai reads your tools

Open Context in OKR.ai and pick a connector. Presets cover engineering, project management, incident and HR tools, with hosted endpoints pre-filled where the vendor publishes one. For a tool without a hosted server, paste the URL of the MCP server your team runs.

• Sign in with OAuth or a token. OAuth follows the MCP authorization spec with PKCE. Tokens are encrypted at rest, refreshed automatically and sent only to that server.
• Read-only by design. The client reads resources and calls only read-only, argument-free tools. It prioritises what matters for OKRs: goals, projects and epics, teams and people, then issues and tickets.
• Compact and cached in your database. Output is converted to compact markdown, stored on the source in the workspace’s own database, and refreshed daily, or on demand.
• Beyond MCP. Crawl a docs or handbook site, add a public strategy or careers page, or upload PDFs, DOCX, Markdown, CSV and JSON.

#What the AI does with that context

Once sources are connected, context flows into every AI feature:

• From context. In My OKRs, AI reads your sources and drafts your OKRs and, when the sources show your team, your team’s OKRs too. Your drafts wait for you to acknowledge; your team’s are proposed to them like a push.
• Existing OKRs first. If your docs already contain written OKRs, they’re shown as written. AI only rewrites them when you click Improve with AI.
• People from your HR system. People in your sources who aren’t in OKR.ai yet are offered, and added only if you tick them.
• Suggest progress. On any key result, Suggest from context estimates the current value from ticket and project status or incidents, and pre-fills the progress form for you to check.
• Pull, push and initiatives. Aligning to your manager, splitting OKRs across reports and drafting initiatives all use connected context automatically.

#An example

Say a VP Engineering connects Jira, PagerDuty and the HR system. Here’s what the sources say, and the shape of the draft that comes back:

The draft uses the real epic names, the incident count as a baseline, the actual team structure, and it aligns to the manager’s objective. You still decide whether 1.2 seconds is the right target.

#Guardrails: AI drafts, you decide

• Context is data, never instructions. Text in a ticket or a doc can’t change the AI’s rules or task.
• Validated output. Every AI answer is checked against a schema, and every id it returns is checked against OKRs you’re allowed to see, before anything is written.
• Nothing saved without you. Suggestions are always shown for editing first, and every change still goes through acknowledge and approve.
• No surprise crawling. Docs and page crawls run behind an SSRF guard that blocks private-network hosts unless an admin allows them.
• Your model, your key. Choose Claude, OpenAI, DeepSeek or any model on OpenRouter. Prompts go only to the provider you configure, never to the OKR.ai project.

The coaching rules the AI follows, covering how to write OKRs, scope by seniority and split targets so they add up, live in a single plain-text file that ships with every install. They encode the same principles as how to write good OKRs and key results that add up.

#Getting good drafts

• Connect the strategy first. A strategy doc, board update or last quarter’s OKRs anchor everything else.
• Add the project tracker. Epics and milestones become initiatives and suggest what key results should measure.
• Add the HR system. Accurate roles and reporting lines let AI scope each person’s OKRs to their function and level.
• Edit ruthlessly. Treat the draft as a strong first pass. Check every baseline and decide every target yourself.

#Try it without an AI key

OKR.ai runs every AI flow with a deterministic stand-in model when OKRAI_MOCK_LLM=1 is set, so you can explore the whole workflow before choosing a provider. Get started in about five minutes, then read the MCP & context docs to connect your first tool.

#Frequently asked questions