Strategy AI agent · OKR & initiatives
OKR & Initiative Tracking AI Agent
Fasten each status claim to something a reviewer can open — a merged change, a signed contract, a launched service — date its last movement, and leave the colour to the named owner.
- Typical delivery
- 4–6 weeks
- Deployment
- Your stack
- Owner-set
- Evidence-bound
- After launch
- Agent Care
What this agent does
Collects the evidence, never the status
In
- 01
A status is set, and the named owner who set it is recorded beside the claim it makes.
- 02
A milestone slips, and the original target stays on the record next to the new one.
Reason
- 03
An initiative goes quiet, and the weeks without movement are reported as plainly as the colour.
- 04
An objective rolls up green, and the worst initiative beneath it is shown beside the aggregate.
- 05
A merged change lands, and the claim it supports is bound to that artefact, not to a form entry.
Decide
- 06
A contract is countersigned, and the initiative resting on it carries the day that happened.
- 07
A service launches, and the objective above inherits evidence rather than an assertion.
Out
- 08
A high-confidence assertion arrives, and it still ranks under a shipped artefact with a low one.
- 09
Execute write actions only inside the approval boundaries agreed during implementation.
Product statement
The agent gathers and dates evidence. A named owner sets the status — the agent grades nobody, and this is not a productivity or performance-management tool.
Example workflow
One initiative, evidence to status
- 1Initiative signals receivedDelivery systems, contract stores, release logs or launch records
- 2Initiative context assembledThe objective above it, the owner named on it, the target it carries and the day it last moved
- 3Evidence pack draftedThe claim, the artefacts under it, the gaps and completeness
- 4Controls appliedMovement checks, evidence-binding checks, baseline checks and completeness confidence
No human action required
Stages 1 to 4 run unaided, and no status is set at any of them — the agent only gathers, and the owner enters at the completeness gate.
Goes to the named owner to set the status.
Adds a portfolio analyst read first.
Portfolio review
The pack is held with its claim, its gaps and the artefacts behind them.
Set status · Append evidence · Send to portfolio review
Status set — by the named owner
- 6Initiative and objective records updatedOnly where write access and records policy allow it
- 7Outcome evaluatedEvidence coverage, movement dating, analyst corrections and what review found
Corrections
Each analyst correction is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required
8 items
- Setting the status on any initiative.
- Judging whether an objective was met.
- Deciding that an initiative is blocked.
- Rating, ranking or appraising a person.
Automation boundary
Agent acts unaided
- ✓Bind each status claim to an artefact that a reviewer could open.
- ✓Date the last movement on every initiative and show it.
- ✓Show the worst constituent beside every roll-up status.
- ✓Keep the original target on the record whenever a baseline is moved.
No status is set and no report leaves the agent except by a named person, on approval.
- Deciding what an objective is worth.
- Telling the board the portfolio is healthy.
- Choosing which initiatives get funded.
- Changes to targets, owners or the status record.
Example output
One status claim, annotated
This serves a strategy or transformation function reporting to an executive team; our performance reporting agent reports campaign delivery for a client, which is a different object entirely.
Evidence pack · single initiative
Illustrative example- Claim
- Platform migration, phase two
- Recorded as
- Evidence gathered, colour left to the owner
- Initiative
- Delivery evidence
- Evidence of record
- Merged change, 3 August 2026
- Confidence
- Held unset
- Held for
- The named initiative owner
As received
Taken from the release log and the contract store — nothing beyond those systems is claimed.
What the record holds
- Merged change
- Signed contract
- Launched service
Why no status is set here
Whether an initiative is green remains an owner judgement, not a model output.
What the score decides
Below the configured threshold a pack picks up an analyst read before the owner sees it.
Action
Set statusAppend evidenceSend to portfolio reviewValue
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value lands
Value 01 – 04
Every claim
From the system that shows it
Where the evidence is used
This is not a productivity or performance-management tool: it reports on initiatives and the evidence beneath them, and it produces nothing at all about individuals.
A status is a claim
A claim wants something observable under it — a merged change, a signed contract, a launched service — rather than an assertion typed into a form.
What was checked, and not found
No external standard defines what green means, so none is quoted here; the thresholds stay yours; and movement dates come only from the systems connected, so an initiative worked outside them will read as quiet.
Build an evidence trail
The initiative, the evidence behind its status and the owner who set it stay together.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Delivery and engineering
- Issue trackers
- repositories
- Merged changes and releases
Planning and objectives
- Objective tree
- baselines
- Targets and re-baselining history
Commercial and legal
- Contract store
- CRM
- Countersigned agreements
Agent
OKR and initiative evidence
- Reads the initiatives
- Gathers the evidence
- Holds for the owner
Launch and operations
- Deployment logs
- service catalogue
- Go-live and launch records
Observability & evaluation
- OpenTelemetry
- Langfuse
- Supported monitoring/evaluation sources
Integration availability depends on the client's existing systems and API access.
Agent controls
Six mills between the model and the owner
Six mills grinding in order, the last the closest set. What passes them all is drawn in the map below.
L6 · Outermost — last line of defence
Inward → L1 · closest to the model
- L1 – L2
- Test whether a claim may stand
- L3
- Leaves the status to a named person
- L4 – L5
- Keep the initiative and the evidence behind it
- L6
- Reverts to raw status when signals degrade
How Nestack evaluates it
Evaluate the whole assembly — not only the evidence pack that comes out.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the pack an executive reads
- E1Final-output evaluationDid the pack record what the delivery systems actually show?
- E2Step-level evaluationDid the agent read the right initiative, the right objective and the live baseline?
- E3Tool evaluationDid it read and write the correct initiative record and the correct objective?
- E4Confidence calibrationDo low-confidence packs actually attract more analyst corrections?
- E5Slice evaluationHow does performance change across specific initiative types?
- E6Business outcomeHow many packs needed a correction before the owner set a status?
Floor — the outcome the executive team answers for
Failure modes
Where each failure originates in the agent
Seven failure modes, each placed at the stage where it first arises.
Agent lifecycle
Direction of processing →
01 · Retrieval
1 mode
- MJ-03
Stale initiative read
The initiative record is not the one the delivery team now works to.
Stage gathers
The goals, the claims, the evidence and the dates
02 · Reasoning
2 modes
- MJ-04
Status asserted, not shown
A colour is claimed with no artefact under it.
- MJ-06
Rollup buries a blocker
An average hides the worst initiative beneath it.
Stage proposes
The claims, their artefacts and completeness
03 · Tool / write
2 modes
- MJ-02
Thin pack passed forward
A pack moves on without the analyst read.
- MJ-05
Evidence bound to wrong initiative
An artefact is filed against the neighbouring workstream.
Stage writes
Only where write access and approval policy allow it
04 · Output
1 mode
- MJ-01
Green, evidence unrecorded
The record shows a colour but not the artefact under it.
Stage returns
The pack an owner sets and an executive reads
05 · Change / Version
1 mode
- MJ-07
Silent baseline drift
A target moves and the record keeps only the newer one.
Stage tracks
Model, prompt, rollup rules and claim fields
- Sev-1 · a status set on no evidence
- Sev-2 · wrong artefact reaches the record
- Sev-3 · source degrades, pack held unset
Affected slices
Cross-team initiatives absorb the corrections
An objective-level evidence-coverage figure can read clean while cross-team initiatives carry most of the rework. Nestack reports the correction rate by initiative type, not only in total.
Slice performance — reported separately, not only in aggregate
Illustrative example| Slice | Failure rate | Lift | Lift vs. threshold | Status |
|---|---|---|---|---|
| Cross-team platform initiatives | 6.9% | 3.6× | Review | |
| Re-baselined initiatives | 4.9% | 2.6× | Review | |
| Partnership and contract initiatives | 3.0% | 1.6× | Watch | |
| Single-team delivery initiatives | 1.2% | 0.6× | Normal |
Bar: correction-rate lift vs. single-team initiative baseline · scale 0–4.0× · tick marks the 2.0× review threshold
2 of 4 slices over threshold
Evidence-linked improvement
What an unevidenced green costs
The loop shuts when the green status without evidence is a regression case. That suite is what the next review pack is measured against.
Improvement cycle · five stages
Switchback — the path turns at Improve and returns at Learn
- 01
Detect
Correction rate rises on cross-team initiatives.
- 02
Diagnose
The initiative that stayed green for two quarters and shipped nothing is worked back through its claims until one cause remains.
- 03
Improve
Any change goes out numbered, with the initiatives that caused it attached.
- 04
Verify
One initiative case still failing is enough to hold the release back.
- 05
Learn
One case joins the suite, one line joins the status record.
Learn → Detect
The return edge. The next pack is measured against a suite one case longer.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, evidence assembly, evaluation, integration, then production validation and handover.
Workstream
Week 1Week 2Week 3Week 4Week 5Week 6
- 01Objective-tree discovery and status-boundary work.Week 1
- 02Delivery, contract and launch sources.Week 1, Week 2
- 03Claim-to-artefact and last-movement-date mapping.Week 1, Week 2
- 04Initiative evidence ingestion.Week 2
- 05Claim, artefact and owner binding.Week 2, Week 3
- 06Completeness scoring and review routing.Week 3
- 07Owner status workflow.Week 3, Week 4
- 08Delivery-system integration.Week 5
- 09Evidence and rollup cases.Week 4, Week 5
- 10Guardrails and attestation controls.Week 4
- 11Initiative-trail instrumentation.Week 5, Week 6
- 12Deployment, documentation and Agent Care handover.Week 6
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel
Final scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
| Capability✓ in scope · — not at this tier | PilotOne objective, one year | ProductionProduction review workflow | AdvancedMultiple objectives / teams |
|---|---|---|---|
| Introduced at Pilot | |||
| Evidence gathering to your objectives | ✓ | ✓ | ✓ |
| Named owner release | ✓ | ✓ | ✓ |
| Tracked-initiative baseline | ✓ | ✓ | ✓ |
| Introduced at Production | |||
| Reporting by objective | — | ✓ | ✓ |
| Owner status workflow in your systems | — | ✓ | ✓ |
| Approved write-back | — | ✓ | ✓ |
| Delivery-system integration | — | ✓ | ✓ |
| Introduced at Advanced | |||
| Multi-level objective trees | — | — | ✓ |
| Cross-team evidence packs | — | — | ✓ |
| Large initiative portfolios | — | — | ✓ |
| Multi-level rollup controls | — | — | ✓ |
| Build price | From $5,000 | From $8,000 | Custom quote |
- Final build price
- Confirmed after discovery based on integrations, workflow complexity, initiative volume, approval controls and deployment requirements.
- Separate from build
- Build pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bring
We build with it
01Your objective tree and the initiatives beneath it
→Objective mapping and initiative capture
Week 102Representative delivery, contract and launch records
→Artefact binding, claim logic and the evidence baseline
Week 203Your standing review cadence and the owners it names
→Objective mapping, artefact binding and the automation boundary
Week 104Access to relevant APIs, feeds or exports
→Delivery, contract and launch source assessment, then integration setup
Week 205Statuses you would not want challenged
→Rollup cases and failure-mode testing
Week 406What no status report may prove
→Completeness scoring, review routing, guardrails and release controls
Week 307A named owner on every objective and initiative
→Release to the named owner, then pilot and production validation
Weeks 5–6
Nothing else is required
Deployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
Widths track what each phase costs to do, so two of them necessarily share the fifth week here.
Phase
W1
W2
W3
W4
W5
W6
- DiscoveryW1
- BuildW2 – W3
- EvaluateW4 – W5
- Pilot & LaunchW5 – W6
Week focus
W1Review workflow discovery, objective mapping and the automation boundary
W2Source integration and the tracked-initiative baseline
W3Evidence gathering, rollup logic and release controls
W4Evaluation suite, rollup cases and stale-initiative testing
W5Delivery-system integration, pilot objectives and targeted corrections
W6One planning year run under the transformation lead, then Agent Care handover
- Reading the band
- Each bar covers only the weeks its own work is named for. The fifth week carries two because the work does.
- At the end of W6
- Once the status record validates, Agent Care assumes the agent.
- Duration
- Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Strategy AI agent
Build an initiative tracker around the green that shipped nothing.
An objective built from many initiatives goes green while one of them is stuck, and the average is what hides it. Show us your rollup and the worst thing beneath it. Every claim comes back dated, and no status is ours to set.
- Typical delivery
- 4–6 weeks
- Deployment
- Your objective tree
- Owner-set
- Evidence-bound
- After launch
- Agent Care available
Nestack Agents · OKR & initiatives
AGT-CS-11 · Agent Care available after launch