Insight · 5 November 2026 · 5 min read
Putting platform agents to work within clear boundaries
Origin Growth’s view is straightforward: assess the workflow before granting the capability permission to act. Start with a narrow task, make its limits enforceable and give someone responsibility for the whole service.
Vodafone Business UK has selected Amdocs for an agentic transformation, according to Telecompaper’s report on 4 November 2026. On the same date, IT Brief UK reported that LogicMonitor was bundling its Edwin offering into every platform tier. These announcements put operational platforms, rather than standalone tools, at the centre of the conversation. They don’t, by themselves, establish what actions customers will allow or how those actions will be governed.
At Origin Growth, we see a practical service-design challenge here: deciding where an agent should assist, where it may act and where it must stop. For UK digital and operations leaders, our recommendation is to start with one bounded workflow, not a broad instruction to automate operations. A capability appearing in a supplier’s platform is a reason to assess it, not permission to switch it loose.
We’d begin with a short workshop involving the process owner, frontline team, platform administrator and someone responsible for security. The output should be a workflow specification that all four can understand. If its boundaries need a lengthy explanation, narrow the task.
Consider an illustrative internal support workflow: preparing a draft ticket for a defined class of monitoring alert. This is a proposed design, not a description of either supplier’s functionality. The intended benefit is less repetitive preparation for the operations team, without handing over decisions about live systems.
Write down the trigger, permitted inputs, output and end point. For example, the agent may receive an alert from a named monitoring source, read approved service records and prepare a draft containing the affected service, alert details and suggested support queue. A person reviews that draft before submission. The workflow ends there.
Make the exclusions equally explicit. No changes to production configuration, no customer messages, no access to unrelated records and no closure of existing incidents. Unknown services and incomplete alerts go to a person rather than through a best-guess route.
This gives the team something concrete to test. It also makes supplier conversations more useful: instead of asking whether a platform supports agents, we can ask whether it supports this exact workflow, with these exact limits.
A written boundary is necessary, but it isn’t a technical control. We would ask the supplier and internal platform team to demonstrate how each limit is enforced before enabling the workflow. Keep capability, configuration and permission separate: what a product can do is not the same as what this service should allow.
For the draft-ticket example, use a dedicated identity with access only to the approved monitoring feed and service records. Give it permission to create a draft in a restricted workspace, not to submit, reassign or close tickets. Avoid borrowing an administrator’s account because it makes the demonstration easier. Convenient access is still access.
Agree the scope of data as carefully as the scope of actions. Which fields are necessary? Which records are excluded? Where are inputs, outputs and activity logs retained, and who can inspect them? Ask for evidence of the controls rather than accepting a general assurance about security.
The review should cover supplier changes too. We recommend requiring an internal check before newly available actions, integrations or permissions are enabled for this workflow. Availability across a subscription tier should not become a shortcut around change approval.
If the platform cannot enforce the agreed boundary, reduce the scope. A read-only recommendation may still be useful. There is no obligation to grant write access simply because it appears on a feature list.
Human escalation needs a destination, a trigger and a response expectation. “Refer to the team” is not enough. In our example, missing service ownership, conflicting records or a suspected duplicate should place the draft in a named review queue, with the reason visible to the reviewer.
We would also make approval meaningful. The reviewer should see the original alert, the records used and the proposed ticket together, rather than receiving an unexplained recommendation and an approve button. They need a straightforward way to edit, reject or report a problem, without wrestling with the interface.
Before a live release, run the workflow against an agreed set of examples. Include ordinary alerts, incomplete inputs, duplicates, unavailable dependencies and records the agent must not access. Where practical, test in an isolated environment with representative data. Don’t make the first operational shift the test plan.
Monitor service outcomes, not just whether the agent ran successfully. For this workflow, we would track draft accuracy, reviewer corrections, escalation reasons, review time and attempted actions outside the permitted scope. These are proposed measures, not reported results. Agree what level of error or unexpected behaviour should pause the workflow before launch.
Provide a tested stop mechanism and a documented manual route. If the agent becomes unavailable or behaves unexpectedly, the support team should still know how to handle the alert. A bounded workflow includes its failure path.
Name a service owner before the pilot begins. That person should be accountable for the workflow’s purpose, boundaries, operating measures and continued suitability, with a clear route to the technical and security teams. Ownership should not disappear between procurement, platform administration and operations.
We recommend a compact operating record: the workflow definition, approved permissions, escalation route, monitoring measures, stop conditions and review date. Add the supplier dependencies and the people authorised to approve changes. Keep it accessible to the team running the service, not buried in a procurement folder.
Start the pilot with draft-only output and a defined review period. The owner can then assess whether the workflow saves worthwhile effort, whether corrections are manageable and whether escalation reaches the right people. Agree acceptance criteria before reviewing the results, rather than redefining success afterwards.
Any expansion should be a separate decision. Automatically submitting tickets, for example, changes the action boundary and deserves fresh testing, permission checks and approval. A successful drafting pilot is evidence about drafting; it is not a licence for broader operational control.
We’re enthusiastic about platforms that can remove repetitive work, but the useful unit of progress is a well-run service, not an enabled feature. If your organisation is assessing a supplier’s new agent capabilities, talk to our team about defining the first bounded workflow — with a clear owner, enforceable limits and a credible path to scale.
