AI applied to strategy execution is only as good as the layer it reads. Given status reports, it produces a well-written restatement of a compression that had already lost the signal. Given task-level records with comments and history, it can flag a slipping goal weeks before a human review would surface it.
The difference is not model quality. It is what the model can see.
What most AI in goal software does today
Scan the category and the AI features cluster into a few shapes. Drafting objectives and key results from a prompt. Rewriting a check-in so it reads better. Summarising a quarter from the updates people typed. Suggesting a confidence score.
These are text operations on text that humans already produced. The underlying facts were fixed before the model arrived, and the facts were thin: a percentage, an on-track label, a two-line update written under time pressure on a Friday. Summarising that produces a tidier version of the same thin picture, delivered with more fluency and therefore more apparent authority. That last part is the risk. A confident paragraph reads as insight whether or not anything underneath it was true.
The job worth doing
There is a genuinely useful role, and it is not writing. It is reading.
A mid-sized organisation generates hundreds of thousands of work signals a quarter: tasks opened and closed, reassignments, comments, blockers raised and never resolved, projects going quiet, threads where something got deprioritised without anyone updating a status field. No human has time to read that volume, and no dashboard aggregates it in a way that preserves meaning.
That is exactly the shape of problem a model handles well. Not "write me an objective" but "across 40,000 task events this quarter, which goals have effort flowing to them that leadership deprioritised in April, and which goals have owners but no work attached." Answering that requires reading everything and knowing which goal each item serves.
Why the data layer decides the output
Three properties of the underlying data determine whether the answer is worth anything.
Granularity. A project-level rollup averages away which task moved and which one froze. A model reading averages inherits the blindness of the average, which is the same reason percent complete is not progress.
Context. The reason work stalled lives in comments and threads, not in status fields. If comments do not travel with the task into the system doing the analysis, the model can see that something stopped and never why. Half the finding is the why.
History. A KPI that has drifted for three weeks and one that tipped over this morning can hold the same value today. Without the change history, both look identical and the urgent one goes unflagged.
Any AI feature built on a layer missing those three is structurally limited, no matter how good the model gets. This is the practical form of the effort-to-goal gap: the analysis can only be as rich as the join between goals and work beneath it.
Deterministic first, model second
A useful split in practice: some checks do not need a model at all, and should not use one.
Whether a goal is running behind pace is arithmetic. Whether a check-in is overdue is a date comparison. Whether a goal has zero connected work is a graph query. Running those deterministically makes them reliable, explainable, and cheap, and it means the alert can point at the exact record that triggered it.
Judgement calls are where the model earns its place. Whether a comment thread describes a real blocker or routine back-and-forth. Whether two teams are building the same thing under different names. Whether the stated reason a project stalled matches what the activity actually shows. Those need language understanding over the raw record, and they need a human to confirm before anyone acts on them.
The mix matters because a system that runs everything through a model is unpredictable, and a system that runs nothing through one misses everything written in prose. The AI agent skills approach to goals and OKRs covers how this looks when the model works against structured work data rather than a text box.
The question to ask a vendor
When an AI feature is demonstrated, ask what it read to produce that output. If the answer is the check-ins and status fields people typed, the feature is a writing aid, which is fine as long as nobody treats it as analysis.
If the answer is the tasks themselves, with their comments, their history, and their connection to a goal, then ask the follow-up: show me a finding, and show me the specific record it came from. A finding that can be traced back to a task and a thread is something a leader can act on. One that cannot is decoration with a confident tone.