As enterprises accelerate the adoption of multi-agent AI systems, a new reality is emerging alongside the excitement: autonomous agents without governance can quickly become a compliance and security risk. From unintended access to sensitive patient records to GDPR violations caused by unrestricted decision-making, organisations are discovering that intelligence alone is not enough. The next phase of enterprise AI will depend on control, specifically, the ability to ensure agents operate within strict, predefined boundaries. In this TechBullion interview, Alexey Spas discusses why control layers are becoming the critical safety foundation for scalable AI, how GENiE by Instinctools was designed to prevent unauthorised agent behaviour, and why responsible AI adoption must embed governance, compliance, and operational safeguards from the very beginning, not as an afterthought.
1) Please tell us more about yourself and the problems you are solving at Instinctools.
My name is Alexey Spas, Founder and CEO of Instinctools. I have over 25 years in software engineering, and have grown Instinctools from a local startup into a global digital transformation company with 400+ professionals serving Fortune 500 clients worldwide.
At Instinctools we help enterprises turn ambitious digital and AI strategies into scalable, robust software, modernizing legacy systems, launching new digital products, and operationalizing emerging technologies like agentic AI in a safe, production-ready way. What makes it work is the combination of strong engineering DNA with people-centric values: teamwork, adaptability, and tight alignment between technology and business goals.
2) Instinctools works with enterprises adopting agentic AI. What is the biggest misconception business leaders still have about multi-agent systems and their real-world capabilities?
The misconception I see most often is treating agents like software features: you turn them on, connect a few tools and let them be. Companies already have proof that agentic AI works: one agent resolves tickets faster, another drafts internal reports, a third moves information across systems with little human help. Once software begins to act, though, the question stops being “what can agents do” and becomes a question of delegation: who owns the agent, where its boundaries are, how its performance is evaluated, and when it should be retired.
A related misunderstanding is conflating orchestration with control. Orchestration answers how agents work together. It does not answer how the enterprise stays in charge of what they are allowed to see, allowed to do, and what can be proven after the fact. McKinsey’s recent AI trust research points in the same direction: nearly two-thirds of respondents name security and risk concerns as the top barrier to scaling agentic AI. So the gap is less about the technology but more about the operating model around it: ownership, lifecycle, guardrails, observability and a trustworthy data foundation.
3) Why do so many organisations struggle to implement multi-agent systems successfully, despite significant investment in AI transformation and automation initiatives?
Most of these struggles come down to investing heavily in capability and underinvesting in the operating model around it. Three patterns come up most often in our work with enterprise clients.
First, diffused ownership. The workflow sits with one team, the model with another, the data with a third, and nobody is fully accountable for how an agent behaves over time. Without explicit ownership and a real life cycle (clear boundaries, performance evaluation, retirement when needed) pilots stall before they reach production.
Second, as I mentioned earlier, organisations conflate orchestration with control. They invest in coordinating agents but skip the control layer that defines what agents are allowed to see, what they are allowed to do, and what can be proven after the fact. Without that layer, more autonomy mostly scales risk.
Third, the foundations underneath are not ready. The same things that separate hyper-productive engineering teams from the rest: decoupled architecture, observability, sandboxed environments, limited credentials. It works for agentic AI as well. On top of monolithic systems and weak data baselines, even good agents amplify existing problems rather than solve them. Add the usual enterprise basics (clear methodology, project management and tight business–engineering communication) and that is what usually separates a successful rollout from an expensive pilot.
4) You have highlighted the importance of a control layer for AI agents. Why is this becoming essential for organisations deploying autonomous multi-agent systems at scale?
At scale, the question stops being whether an individual agent works and becomes whether the organisation can stay in charge of many of them acting on its systems at the same time. That is what makes a dedicated control layer essential rather than optional.
Two shifts make this urgent. Agents are increasingly sitting on top of core platforms like ERP and CRM rather than replacing them, so the supervisory layer becomes the place where the enterprise actually exerts control. And the problem itself has moved from access control (what an agent is allowed to see) to action control (what it is allowed to do, and what can be proven after the fact).
Underneath all of this sits the data foundation. Agents are only as trustworthy as the enterprise reality they operate in: unified data, workflows, policies, approval hierarchies.
5) We are seeing cases where AI agents unintentionally access protected data. How serious is the compliance risk for businesses operating without proper safeguards?
It is serious, and it is not hypothetical, incidents are already happening. McKinsey’s recent AI trust research found that almost 60% of organisations that experienced an AI incident rated their own response as only satisfactory or worse, which suggests many companies are not equipped to handle these situations even after the fact.
The exposure has two layers. The familiar one is what an agent is allowed to see. The harder one at scale is what it is allowed to do, and whether the organisation can prove afterwards what actually happened. That is why the conversation has shifted from access control to action control — identity, permissions, logging, audit trails and action-level guardrails for digital co-workers, with sandboxed environments and limited credentials underneath.
Without that, an unintended data access stops being a technical incident and becomes a compliance problem: you cannot reconstruct what happened, you cannot demonstrate due diligence, and you cannot reliably prevent it from happening again.
6) GENiE serves as a control layer designed to restrict unauthorised agent actions. How does this approach balance operational flexibility with governance and security?
Flexibility and control sit in different layers of the platform, so reinforcing one does not come at the cost of the other.
On the flexibility side, GENiE is vendor-agnostic: it runs on top of whatever stack a client already has and lets us mix open-source frameworks like crewAI, LangChain and Agno with vendor platforms such as Azure Agent Framework, AWS Bedrock AgentCore or IBM Agent Development Kit in one workspace. A task-adaptive hybrid architecture and OpenAPI-first integration mean agents can stay creative where it helps and deterministic where it matters.
On the governance side, the same platform has responsible AI mechanisms built in: bias detection and mitigation, regulatory compliance checks, agent behaviour guardrails, tool access limitations and visual monitoring of interactions, performance and spending. Context is segmented into hot, warm and cold layers, so an agent only sees what it needs for the task at hand.
The balance works because the control layer operates around the agents at orchestration, context and tool-access level rather than restricting the underlying models. Agents stay free to reason and act within their domain, while the enterprise keeps clear boundaries and visibility over what they actually do.
7) Do you believe existing regulations such as GDPR are sufficient for governing autonomous AI agents, or is the regulatory landscape struggling to keep pace?
Frameworks like GDPR, HIPAA and SOX were designed for a world where a human, or at most a deterministic system, decides what happens to data. Autonomous agents break that assumption: they reason over data, combine it across systems, and take actions on behalf of the business. The vocabulary still applies (lawful basis, purpose limitation, accountability) but the unit of control no longer fits.
The EU AI Act moves in the right direction with risk tiers, transparency and human oversight requirements, but it still regulates mostly the model or the system, not the agent’s behavior in production. That’s where the hard questions sit: who is accountable when an agent chains several tools together and produces a non-compliant outcome that none of the tools would have produced on their own?
8) What are the biggest risks organisations face when AI safety and governance are introduced after deployment rather than embedded from the start?
The core risk is that retrofitting governance rarely restores the visibility and control you would have had by design. Once agents live on top of ERP, CRM and core data, you inherit whatever boundaries and logging you happen to put in place and changing that later is hard without disrupting the business.
Three patterns show up consistently. Ownership stays diffused: no one owns the agent’s lifecycle from day one, so boundaries, performance evaluation and retirement criteria never get defined. You get orchestration without control: agents coordinate across systems, but the layer that says what they are allowed to see, allowed to do, and what can be proven after the fact is missing and more autonomy on that foundation mostly scales risk. And weak foundations get amplified: monolithic systems, poor observability and broad credentials do not stay neutral once agents act on them at machine speed.
9) As multi-agent ecosystems expand, how should businesses approach accountability when an AI agent makes a harmful or non-compliant decision?
Accountability is about people, not the agent. In a multi-agent setup, the answer is a clear chain: every agent has a named human owner, a defined scope of what it can see and do, and a lifecycle with performance evaluation and retirement criteria.
The second piece is reconstructability. When an agent makes a harmful or non-compliant decision, the organisation should be able to show what context it had, what tools it called, which guardrails fired, and where a human approved or overrode it. That is exactly the shift from access control to action control, supported by identity, permissions, logging and audit trails for digital co-workers. If you can answer those questions in minutes, an incident stays a technical event. If you cannot, it becomes a compliance one.
10) Looking ahead, what will separate organisations that scale agentic AI responsibly from those that fail to manage the operational and compliance risks?
In my view, the difference will come down to operating discipline rather than technology. The organisations that scale agentic AI responsibly will treat it as a long-term capability, not a series of pilots: clear ownership for each agent, an honest view of its value against its cost, and steady investment into the operating model around it — control layer, observability, audit trails, a strong data foundation.
The ones that struggle will keep adding agents without that discipline. Their inventory will grow, their visibility will not, and sooner or later an incident will force them to slow down and rebuild what should have been there from the start. In the end, the gap will not be about who has the most agents, but about who keeps a clear head as they scale.
