The Program Agent
Programme status meetings exist because nobody can answer *are we ready* from the system. The information is all there; it is spread across six object types and nobody has time to gather it weekly.
The question it answers
Is this programme ready to release, and if not, what specifically is stopping it. Not a health score, not a percentage, not a traffic light — a list of the things that are open, with what each one is waiting on.
Six categories account for nearly all of it: open changes against items in the structure, unverified requirements, open nonconformances and CAPAs, items with no approved manufacturer, documents in a state below release, and expiring deviations that were covering something during development.
Each is a query. The agent's contribution is not the query — it is running all six across a programme's resolved structure, every day, and presenting the union as one list with the blocking ones separated from the merely open ones.
The distinction between blocking and open is configuration rather than judgement: gate conditions from the rules engine determine what actually prevents a release. The agent reports against those rules rather than inventing its own opinion about severity.
Why not a percentage
Readiness percentages are the most requested and least useful output in programme management. They compress a list of specific, actionable items into a single number that cannot be acted on and can be argued with indefinitely.
Ninety-four percent ready is not a fact about a programme; it is a fact about a weighting somebody chose. Change the weighting and the number changes without anything about the programme changing, which is exactly the property a status metric must not have.
The alternative is duller and better: eleven open items, four of which block release, each naming its owner and what it is waiting on. That list is the same whoever generates it, it changes only when the programme changes, and every row is something a person can do something about this afternoon.
Where a trend is genuinely useful, the count over time is shown — open blocking items per week — which is a real measurement rather than a constructed one.
The failure it prevents
A programme is declared ready at a gate review. The review covers the items each function brought, and each function brought what they knew about.
Three weeks later, production cannot raise a work order because two items in the structure have no approved manufacturer. Nobody was tracking that — it was not any function's standing report, and it was true for four months before anyone looked.
Gate reviews cover what people bring. The whole class of gap that nobody owns survives them, and the items with no AML entry are the canonical example: engineering assumes procurement, procurement assumes engineering, and the query that would have found it in a second was never run.
How it meets the rest of the product
It resolves the programme's structure the same way every other query does, so what counts as *in this programme* is the resolved configuration rather than a manually maintained list of items that drifts within weeks.
Findings link to the objects they concern, so a status list is navigable rather than descriptive. An open nonconformance on the list opens the nonconformance, which is a small thing that changes whether the list is used.
The other agents supply most of the underlying findings. Requirements coverage comes from the Requirements Agent, stale documents from the Documentation Agent, drift from reconciliation — and this one composes them into a single answer rather than duplicating the analysis.
It runs at Observe tier. It reports; it does not close items, reassign owners, chase people or change a programme's state. A readiness report produced by something that could also close items would be reporting on itself, which is the one arrangement that makes the output worthless.
How it meets your ERP
Two of the six categories are ERP-facing, and they are the ones that fail latest and loudest: items that do not exist in the ERP item master, and structures whose last publication did not reconcile cleanly.
Both are invisible from inside engineering and both stop production dead. Including them in a readiness view is the difference between a programme that is ready in the PLM and one that is ready to build, which are not the same claim.
Where ERP reads are configured, the agent can also report on lead-time exposure — items in the structure with lead times longer than the remaining schedule. It states the fact and names the items; the response is a planning decision that belongs to people.
Where the boundary is
It does not produce a readiness score. The output is a list of open items with owners and blockers, because a number cannot be acted on and can be argued with indefinitely.
It also does not manage the programme. It does not assign work, set dates, escalate, close items or notify people on a schedule of its own. It answers a question when asked and raises tasks for what it finds, and the programme stays owned by whoever owns it.
Facts
| The question | Is this ready to release, and what specifically is stopping it |
| Six categories | Changes · requirements · quality · AML gaps · documents · deviations |
| Blocking versus open | Determined by gate conditions in the rules engine |
| No score | 94% ready is a fact about a weighting, not about a programme |
| Trend shown | Open blocking items per week — a real measurement |
| Scope | The resolved structure, never a maintained item list |
| ERP categories | Missing item master entries · unreconciled publications |
| Tier | Observe only — it never closes, assigns or escalates |
Frequently asked
Why refuse to give a readiness percentage?
Because ninety-four percent ready is a fact about a weighting somebody chose rather than a fact about the programme. Change the weighting and the number moves without anything real having changed, which is precisely the property that a status metric must not have.
What does it give instead?
Eleven open items, four of which block release, each naming its owner and what it is waiting on. That list is the same whoever generates it, changes only when the programme changes, and every row is something somebody can act on this afternoon.
What decides whether an item blocks release?
The gate conditions configured in the rules engine, not the agent's opinion. It reports against your rules rather than inventing a severity model of its own, which keeps the definition of blocking in configuration where an administrator can read and change it.
Which gap does this catch most often?
Items in the structure with no approved manufacturer. Engineering assumes procurement is handling it, procurement assumes engineering is, it appears on nobody's standing report, and it surfaces three weeks after a gate review when a work order cannot be raised at all.
Why include ERP conditions in a readiness view?
Because ready in the PLM and ready to build are different claims. Items missing from the ERP item master and structures whose last publication did not reconcile are invisible from inside engineering, and they are what stops production dead on the day.
Does it chase people or escalate?
No. It does not assign work, set dates, escalate, close items or notify on a schedule of its own. It answers the question and raises tasks for what it finds; the programme stays owned by whoever owned it before the agent existed.
Why is Observe tier the right limit here?
Because a readiness report produced by something that could also close the items it counts would be reporting on itself. Keeping the agent unable to change what it measures is what makes the measurement worth reading at all in a gate review.