The Future of Agentic as a Service
Agentic as a Service is likely to evolve from broad demonstrations into narrower, more dependable operating services.
The early market often presents agents as general digital workers.
The more durable direction is different.
Successful GaaS offerings are likely to become:
- more specialised;
- easier to connect;
- easier to inspect;
- more tightly governed;
- available across local, private, and cloud environments;
- measured by accepted outcomes;
- integrated into existing workflows; and
- designed around clear human decision rights.
The future of GaaS is therefore not simply a future of greater autonomy.
It is a future in which agentic capabilities become more useful because their tools, responsibilities, limits, and evidence are clearer.
From general agents to specialist services
General-purpose agents are attractive because they appear able to handle many tasks.
In practice, broad scope makes them difficult to test and govern.
Specialist GaaS offerings are likely to focus on bounded outcomes such as:
- preparing account briefs;
- reviewing project risks;
- collecting missing documents;
- monitoring supplier changes;
- triaging support requests;
- organising audit evidence;
- checking operational exceptions; or
- preparing approved system updates.
A specialist service can use:
- a limited tool set;
- known sources;
- defined output;
- repeatable validation;
- focused evaluation;
- narrow permissions; and
- clear escalation rules.
This makes performance easier to measure.
It also gives customers a clearer reason to adopt the service.
GaaS will become more workflow-centred
Agents are unlikely to replace structured workflows entirely.
Instead, agentic decisions will increasingly appear inside controlled processes.
A future GaaS workflow may look like:
Validate Request
→ Agent Selects Approved Evidence
→ Deterministic Policy Check
→ Agent Prepares Recommendation
→ Human Approval
→ Controlled External Action
→ Verify Outcome
The workflow defines the required sequence and controls.
The agent handles uncertainty within selected stages.
This combination offers more flexibility than rigid automation and more predictability than unrestricted agent execution.
Interoperability will become a core requirement
GaaS providers need to connect agents with tools, data, applications, and other agents.
Proprietary one-off integrations are expensive to maintain.
Open and shared protocols can make it easier to:
- describe capabilities;
- discover tools;
- exchange structured context;
- delegate tasks;
- return task status;
- coordinate several agents;
- change providers; and
- audit the complete action path.
Model Context Protocol supports a common way for AI applications to connect with tools and contextual resources.
Agent-to-agent protocols are developing around communication and task coordination between separate agent systems.
These approaches address different layers.
Tool interoperability allows an agent to use a capability.
Agent interoperability allows one agent or service to delegate work to another.
Interoperability will not remove governance
A standard connection can make integration easier.
It does not make every connected tool trustworthy.
Future GaaS environments will still need to verify:
- tool owner;
- server owner;
- agent identity;
- account;
- input schema;
- output schema;
- read or write behaviour;
- source;
- destination;
- permission scope;
- activity evidence; and
- revocation process.
Interoperability increases the number of possible connections.
Governance determines which connections should be allowed.
Agent discovery will become more structured
Users and systems will need reliable ways to understand what an agent can do.
A future agent description may include:
- name;
- purpose;
- supported tasks;
- required input;
- expected output;
- tools;
- data requirements;
- permissions;
- limitations;
- service owner;
- availability;
- evaluation status; and
- approval requirements.
Clear capability descriptions will help organisations choose the correct service.
They may also reduce the risk of assigning a task to an agent that lacks the required authority or expertise.
GaaS marketplaces may emerge
Interoperable descriptions can support catalogues or marketplaces of specialist agentic services.
Organisations may be able to select services for:
- research;
- customer operations;
- document review;
- finance preparation;
- IT support;
- project monitoring;
- data quality; or
- procurement operations.
A responsible marketplace would need more than ratings and promotional claims.
It would need to show:
- provider identity;
- service scope;
- supported tools;
- data handling;
- evaluation evidence;
- permissions;
- incident history;
- pricing;
- portability; and
- termination conditions.
The quality of market information will affect whether such marketplaces are trustworthy.
Multi-agent services will become more common—but selective
Some future services will use several specialist agents.
One agent may plan.
Another may retrieve evidence.
Another may verify the result.
Another may prepare the final output.
Multi-agent coordination can help when a task benefits from:
- specialist roles;
- independent verification;
- parallel work;
- separation of duties;
- different models; or
- controlled delegation.
It also introduces additional complexity.
Providers must manage:
- handoffs;
- shared state;
- conflicting conclusions;
- repeated work;
- agent identity;
- task ownership;
- cost;
- latency; and
- final authority.
The future is unlikely to involve adding more agents to every task.
Strong services will use the smallest effective architecture.
Orchestration will become a separate service capability
As agent ecosystems grow, orchestration will become increasingly important.
Orchestration determines:
- which agent receives a task;
- which model is suitable;
- which tool may be used;
- whether work runs sequentially or in parallel;
- how context is passed;
- how state is preserved;
- when a reviewer is involved;
- how failures are recovered; and
- when the complete process stops.
Customers may evaluate the orchestration layer separately from the individual agents.
A service with excellent specialist agents can still fail if its routing and handoffs are weak.
Local and hybrid GaaS will expand
GaaS does not need to run entirely in a public cloud.
Future services are likely to combine:
- local models;
- private models;
- cloud models;
- local files;
- local MCP servers;
- private databases;
- remote business applications;
- provider-managed orchestration; and
- customer-controlled execution.
A hybrid service may keep sensitive document processing on a local device while using an approved remote system for a final business action.
Another service may use a cloud model for general reasoning but keep all source files inside a private environment.
Hybrid design gives customers more choices around privacy, performance, availability, and cost.
It also makes the data path more complex.
On-device agents will create new service models
Improvements in local hardware and models can support agentic work directly on personal and organisational devices.
On-device services may offer:
- lower latency;
- offline operation;
- local file access;
- reduced remote data movement;
- personal context; and
- continued work during network interruptions.
Providers may sell a managed GaaS capability while execution occurs partly on customer-owned hardware.
This changes operational responsibility.
The provider may manage the agent and workflow, while the customer manages:
- device health;
- local storage;
- power;
- operating-system access;
- model availability;
- local services; and
- backups.
Future service agreements will need to explain this shared model clearly.
Agent workspaces will become visible to users
Agentic work often happens across several hidden steps.
Future user interfaces are likely to make that work more visible.
An agent workspace may show:
- current goal;
- planned stages;
- active tool;
- retrieved sources;
- progress;
- pending approval;
- warnings;
- completed actions;
- cost;
- final outcome; and
- remaining exceptions.
This will shift users away from treating agents as chat interfaces.
The important interface will be the task and its evidence.
Background execution will require stronger controls
Agents will increasingly perform long-running or scheduled work without a person watching every step.
This can improve capacity.
It also requires:
- isolated execution;
- named agent identities;
- narrow permissions;
- status visibility;
- pause controls;
- expiration;
- resource limits;
- approval queues;
- failure notification; and
- verified external actions.
Background work should never mean invisible work.
Human roles will move toward supervision and exception handling
GaaS can reduce repetitive preparation and coordination.
Human work will increasingly focus on:
- defining goals;
- approving access;
- reviewing exceptions;
- resolving ambiguity;
- assessing evidence;
- handling relationships;
- making high-impact decisions;
- improving workflows; and
- accepting accountability.
This change requires new operating skills.
Employees need to understand:
- how to define a task;
- how to review agent evidence;
- when not to trust an outcome;
- how to correct a workflow;
- how to stop execution;
- how to report an incident; and
- when professional judgement must remain human.
Decision rights will matter more than “human in the loop”
The phrase human in the loop is too broad for mature services.
Future GaaS governance will define precise decision rights.
For each action, the organisation should know:
- what the agent may decide;
- what the agent may recommend;
- what requires approval;
- who may approve it;
- which evidence is required;
- whether approval expires;
- what happens after rejection; and
- who owns the final outcome.
A reviewer who sees only a general “approve” button does not provide strong oversight.
Agent identity will become a standard control
Organisations will need to know which agent acted.
Important activity records will increasingly identify:
- initiating user;
- agent;
- agent version;
- workflow;
- workflow version;
- account;
- tool;
- source;
- destination;
- reviewer;
- timestamp; and
- service provider.
Agent identity will support access control, audit, investigation, billing, and service management.
Shared anonymous agent accounts will become less acceptable for important work.
Permission models will become more granular
Traditional application roles may be too broad for agents.
Future GaaS permissions are likely to become task-specific.
An agent may receive access limited by:
- one workflow;
- one customer;
- one project;
- one source;
- one destination;
- one record type;
- one action;
- one time period;
- one task; or
- one approval.
Temporary permissions may be granted only during execution and removed when the task ends.
This can reduce the impact of mistakes or compromised agents.
Governance will become continuous
A one-time launch review is not enough for an agentic service.
Models, tools, sources, workflows, and provider dependencies change.
Future governance will monitor:
- agent inventory;
- tool inventory;
- access;
- model changes;
- workflow versions;
- evaluation results;
- incidents;
- exceptions;
- memory;
- cost;
- provider changes;
- user adoption; and
- continued business value.
Services may need approval again after a material change.
Evaluation will move closer to production
Pre-launch tests remain important.
They cannot represent every real input, source change, or tool failure.
GaaS evaluation will increasingly include production signals such as:
- accepted-outcome rate;
- human correction;
- exception quality;
- tool-selection accuracy;
- wrong-destination attempts;
- duplicate prevention;
- false-completion rate;
- runtime;
- cost;
- reliability; and
- user trust.
Providers will need to detect gradual behaviour changes rather than only obvious outages.
Verifiability will become a competitive advantage
Customers will increasingly prefer services that can prove what happened.
Verifiable GaaS may provide:
- source references;
- record identifiers;
- deterministic checks;
- action confirmations;
- approval history;
- signed activity records;
- workflow versions;
- evaluation evidence; and
- reproducible test cases.
A confident result without evidence will be less acceptable for operational tasks.
Outcome-based service models will grow
GaaS shifts attention from software access to completed work.
This may encourage pricing based on:
- accepted reports;
- resolved requests;
- processed document packages;
- completed reviews;
- approved updates;
- monitored entities; or
- service capacity.
Outcome pricing sounds simple but requires careful definitions.
Providers and customers must agree on:
- what counts as completion;
- required quality;
- treatment of exceptions;
- treatment of corrections;
- failed or partial work;
- duplicated actions;
- human contribution; and
- evidence of acceptance.
Mature outcome pricing will depend on mature measurement.
GaaS will become part of broader service contracts
Agentic capabilities may be bundled into existing managed services.
A provider may no longer sell only:
- support software;
- research software;
- project software;
- document software; or
- operations software.
It may offer a managed outcome that combines software, agents, human review, and operational support.
This can blur the line between software vendors, consulting firms, business process outsourcers, and AI providers.
Contracts will need to clarify which work is performed by agents, people, or both.
Portability will become a buying requirement
Customers will not want important processes trapped inside one provider.
Future buyers are likely to request export for:
- agent instructions;
- workflows;
- tool mappings;
- prompts;
- policies;
- memory;
- activity records;
- evaluation results;
- approval history; and
- business data.
Open protocols can improve technical portability.
Commercial portability also requires clear contract terms, documented formats, and a practical transition process.
Provider ecosystems will consolidate and specialise
The market may develop several kinds of GaaS providers:
- general agent platforms;
- industry-specific services;
- function-specific services;
- local and private deployment providers;
- orchestration providers;
- managed integration providers;
- evaluation and governance providers; and
- human-agent operations providers.
Some providers will combine several categories.
Others will focus on one layer and connect through open protocols.
Customers should avoid assuming that one provider must manage every layer.
Security will move from model controls to action controls
Traditional AI security often focuses on model input and output.
Agentic services require controls around actions.
Future GaaS security will increasingly examine:
- what the agent can reach;
- which account it uses;
- what it can change;
- which destination is allowed;
- how a task is authorised;
- how a write is confirmed;
- how activity is attributed;
- how delegation is limited; and
- how the service is stopped.
The tool layer may be more consequential than the generated text.
Regulation will focus on deployed behaviour
Rules and standards are likely to pay increasing attention to what agents do in practice.
Important questions include:
- Is the system making or supporting a high-impact decision?
- Can affected people understand the role of automation?
- Is a qualified person accountable?
- Are records available?
- Can the action be challenged?
- Are permissions proportionate?
- Is monitoring continuous?
- Can the organisation stop the service?
- Are providers and subcontractors known?
Compliance will depend on the use case and location, not only the agent label.
Self-improving services will require strict change control
Some agents may optimise prompts, plans, routing, or tool selection based on previous performance.
This can improve efficiency.
It can also create behaviour changes that were not reviewed directly.
Self-improvement should be constrained by:
- approved objectives;
- fixed boundaries;
- versioning;
- evaluation;
- change thresholds;
- human approval;
- rollback;
- monitoring; and
- protected test environments.
A service should not modify its own access or safety rules.
Feluda and the future of user-controlled GaaS
Feluda's combination of models, workflows, tools, local execution, and scheduling reflects several likely GaaS directions.
Studio can keep agentic decisions inside visible workflows.
AI Providers can support model choice across local and cloud options.
MCP servers and Genes can expose focused capabilities.
Workbench Activity and RunFlows can help users inspect tool execution and workflow results.
Schedule Manager can support recurring agentic work with pause and review controls.
Local model and desktop operation can support private or hybrid service designs.
These capabilities can help users create GaaS offerings in which the execution path remains more directly controlled by the service operator or customer.
What organisations should prepare for now
Organisations do not need to predict every technical development.
They can prepare by creating durable capabilities.
These include:
- clear process ownership;
- agent and tool inventories;
- narrow access;
- reusable evaluation cases;
- portable workflows;
- activity records;
- human decision rights;
- incident response;
- provider exit plans;
- local and cloud deployment options; and
- outcome measurement.
These practices remain useful even when models and protocols change.
What is unlikely to change
The technology will evolve.
Several operating principles are likely to remain important:
- unclear tasks produce unclear outcomes;
- broad permissions increase impact;
- important actions need evidence;
- external writes need confirmation;
- retries can create duplicates;
- providers need accountable ownership;
- users need practical stop controls;
- high-impact decisions need qualified humans;
- services need continuous evaluation; and
- value must be measured through accepted outcomes.
The practical conclusion
The future of GaaS will be shaped less by one universal autonomous agent and more by networks of specialised, interoperable, governed services.
Agents will work inside workflows.
Workflows will connect through shared protocols.
Execution will move between local, private, and cloud environments.
Human roles will shift toward defining goals, supervising exceptions, and accepting responsibility for important outcomes.
The leading providers will not be those that hide the most complexity.
They will be those that turn complexity into a service that remains understandable, portable, measurable, and safe to operate.