Where agent output actually lands
The most common way an AI feature fails is not a wrong answer. It is correct output arriving somewhere nobody looks, ageing quietly, and being discovered three weeks later when it no longer matters.
What it is, and what it is not
Agent output — drafts, proposals, flagged exceptions, questions requiring a person — arriving as tasks in the same queue as approvals, reviews and reconciliation items.
It is not a separate AI inbox. That is the design almost everybody reaches for and it fails for a structural reason: a second queue competes for attention with the first, loses, and becomes the place work goes to be ignored. The integration console nobody opens is the same pattern.
It is also not a notification stream. A feed of things that happened is not a list of things to do, and conflating them means the actionable item and the informational one look identical at a glance.
The mechanism: agent tasks are tasks
An agent proposal is a workflow task with everything a task has: an assignee, an age, a due date where one applies, and escalation when it is not answered.
Escalation is the part that matters. A drafted change sitting unreviewed for eleven days escalates the same way an unanswered approval does — the manager is notified, the task stays assigned rather than silently reassigning. Without that, agent output has no floor: it can age indefinitely because nobody owns it.
Tasks carry their evidence rather than a summary. A flagged duplicate names the three part numbers, their AML entries and the products each is used in; a drafted ECR carries its impact set and its recommended reviewers with the relationship paths that produced them. Review is only real if the evidence is in the task rather than a click away.
Priority comes from what the item blocks, not from how confident the agent was. A component risk alert on a shipping product outranks one on a part nobody has built in three years, and confidence scores are deliberately not part of the ordering.
The failure it prevents
An organisation enables agents. The output is good — accurate duplicate detection, sensible change drafts, well-scoped risk alerts. Everybody is pleased in the first fortnight.
The output lands in an AI section of the interface. People visit it when they remember, which is often at first and then less. After six weeks the section holds two hundred items, most still relevant, and opening it now feels like starting a project rather than doing a task.
Somebody eventually declares AI bankruptcy on the backlog and clears it. The feature was working the entire time, and the organisation concludes that AI in PLM does not deliver — which is a reasonable inference from what they observed and completely wrong about the cause.
How it meets the rest of the product
The queue runs on the same workflow engine as everything else, so agent tasks inherit durability: state lives in the task row, an instance survives a restart, and a timer fires on the date it was set for regardless of what was running.
Acting on a task uses the ordinary path. Accepting a drafted change submits it into change control with an impact set and approvals; accepting a consolidation runs a mass change against the reviewed set. Nothing about accepting agent output bypasses a process a human action would go through.
Every task carries the agent, its permission tier and the object revisions cited, so the audit trail records not just that somebody accepted a proposal but what they were shown when they did.
Dismissing a task is recorded too, with a reason where one is given. That matters more than it sounds: a proposal type dismissed forty times is telling you something about the agent's configuration that no accuracy metric will.
How it meets your ERP
Reconciliation tasks from the connectors land in the same queue, which is the point at which this design pays for itself twice. A difference between Manufacturing PLM and your ERP is work somebody must do, and putting it in an integration console guarantees only IT ever sees it.
Agent tasks and connector tasks about the same object group together, so a component risk alert and an unreconciled quantity on the same part appear as one situation rather than two unrelated items in two places.
Tasks carry ERP context where the connector provides it — on-hand, open orders, lead time — so the decision is made with the operational consequence on screen rather than requiring a second system to be opened.
Where the boundary is
A queue does not create attention. An organisation that generates four hundred agent tasks a week has moved the bottleneck rather than removed it, and reviewing them badly is worse than not generating them — the honest response is fewer, better-targeted agents rather than a bigger queue.
It also does not decide what matters. Priority is derived from what an item blocks, which is a structural signal rather than a judgement about importance. A task nobody has actioned in a month may be correctly deprioritised or may be the one that costs you a quarter, and no ordering rule can tell the difference.
Facts
| Lands in | The ordinary work queue — never a separate AI inbox |
| Task shape | Assignee · age · due date · escalation |
| Escalation | Same as an unanswered approval; stays assigned |
| Evidence | Carried in the task, not a click away |
| Priority | From what it blocks — never from agent confidence |
| Accepting | Uses the ordinary process; bypasses nothing |
| Dismissals | Recorded with a reason — the most useful signal you get |
| Does not | Create attention, or decide what genuinely matters |
Frequently asked
Why not a dedicated AI inbox?
Because a second queue competes with the first for attention, loses, and becomes where work goes to be ignored. It is the same pattern as the integration console nobody opens — the design looks tidy and produces a backlog somebody eventually declares bankruptcy on.
What stops agent tasks from ageing quietly?
Escalation, identical to that on an unanswered approval. A drafted change sitting unreviewed for eleven days notifies the manager, and the task stays assigned rather than silently reassigning itself. Without that, agent output has no floor at all, because nobody actually owns it.
How much evidence does a task carry?
All of it, rather than a summary with a link. A flagged duplicate names the three part numbers, their approved manufacturer entries and the products each is used in. Review is only real when the evidence is in the task rather than one click and a decision away.
How are tasks prioritised?
By what the item blocks. A component risk alert on a shipping product outranks one on a part nobody has built in three years. Agent confidence is deliberately not part of the ordering, because a confident wrong proposal should not outrank an uncertain correct one.
Does accepting a proposal skip approval?
No. Accepting a drafted change submits it into change control with its impact set and approvals; accepting a consolidation runs a mass change against the reviewed set. Nothing about agent output bypasses a process that the equivalent human action would go through.
Do connector reconciliations land here too?
Yes, and it is where the design pays for itself twice. A difference between Manufacturing PLM and your ERP is work somebody must do, and putting it in an integration console guarantees that only IT ever sees it while the person who can resolve it never does.
What if we are drowning in agent tasks?
Then you have moved the bottleneck rather than removed it, and reviewing them badly is worse than not generating them at all. The honest response is fewer and better-targeted agents rather than a larger queue with a more sophisticated ordering rule on top.