How We Integrated AI Agents into the SimpleOne Platform: Architecture, Scenarios, and Security

In a corporate environment, AI assistants quickly hit a ceiling: they can answer questions, but they can't execute tasks. You can ask for information, but you can't instruct them to generate a ticket, compile incident data, send a digest, or locate related objects.

Meanwhile, AI agents are dominating industry conversations. Unlike a chatbot or a standard assistant, an agent operates autonomously. Upon receiving a request, an AI agent evaluates its available tools and decides the optimal sequence to use them. There are no rigid, predefined scripts — only a set of methods and instructions defining what the agent is authorized to do.

In this article, the SimpleOne team breaks down the architecture of agents within our GenAI platform: their core components, how they integrate into business processes, and what they can achieve in a production environment.

GenAI operates across all layers of our platform: in Low-code tools, in ESM, and within ready-made business applications like ITSM. In SimpleOne, AI is a native platform layer, sitting seamlessly alongside access rights, workflows, and business rules.

Our technology partner, Ainergy, handles model orchestration. The architectural foundation of the SimpleOne platform ensures secure interaction with corporate knowledge via RAG (Retrieval-Augmented Generation) and security mechanisms. Specific, universal tools are built on top of this foundation: autonomous agents, ready-to-use AI services for workflow integration, and UI interfaces.

This approach is how AI agents became an integral part of our platform's business processes. Here is how an agent is structured:

The Agent is a configuration combining an instruction and an adapter. The instruction defines the agent's identity and function: its working context and the specific problems it solves. Essentially, it is a system prompt. For example: "You are an incident analyst. Every day, you gather incidents closed within the last 24 hours and format them into a Knowledge Base article." The agent connects to an adapter, which grants it access to its tools.

The Adapter is a reusable toolkit. An administrator configures it once and can connect it to multiple agents. While the platform itself may host a vast array of methods, a specific agent only sees the tools included in its assigned adapter. One adapter can serve multiple agents; for instance, a general toolkit for reading platform data doesn't need to be recreated for every single agent.

The adapter unites two types of tools: methods and MCP tools. To the agent, they are functionally identical — it simply sees a unified list and selects the right tool for the job.

Methods are tools executed inside the SimpleOne platform: fetching data from a table, creating a record, or triggering a script. Administrators describe and add these to the adapter. An agent physically cannot execute an action absent from its adapter; it cannot invent tools on the fly.

Tools are actions the agent can invoke via an MCP (Model Context Protocol) server: fetching external data, finding a document, creating a record, or interacting with a third-party system.

Nexus is the routing gateway to the language model. This is where you define which LLM is used, which endpoint to call, and with what parameters. A single Nexus can be connected to multiple agents, allowing administrators to swap out the underlying AI model globally with a single configuration change.

When an agent receives a task, the language model reviews the list of available tools in its adapter, reads their descriptions, and decides which tool to call, what parameters to pass, and how to process the result. There is no hard-coded sequence of steps; the agent dynamically builds the execution path to achieve the target goal.

A crucial architectural feature is the hybrid execution model for agents. By default, agents run in a native runtime within SimpleOne — the exact same environment hosting your business data and processes. The agent accesses platform objects directly, without relying on intermediary integrations or external containers. Any action available to a user in the UI is available to the agent at the platform level. This guarantees direct data access, predictable security (data never leaves the corporate perimeter), and fewer points of failure compared to external runtime architectures.

Simultaneously, the platform supports external agent runtimes via MCP. This caters to scenarios where a client already maintains their own agent infrastructure on an open-source stack, or when the required data resides in external systems rather than inside SimpleOne. Both approaches can be seamlessly combined within a single platform.

Do you need an agent if you already rely on workflows? Generally, yes — but not for every task. In a standard workflow, the inputs and outputs at each step are predictable, allowing you to map the entire process in advance. An agent is necessary when the situation varies every time, and you simply cannot hard-code every possible branching scenario.

For example, in a Service Desk, a user might submit a ticket saying anything from "it won't open" to "everything is broken" or "I haven't been able to log in since yesterday." An agent autonomously determines what clarifying questions to ask, where to fetch the required data, and what response to formulate. There is no fixed script; every request is unique. This is where agentic AI delivers maximum value.

Conversely, consider the agent-analyst example mentioned earlier. Every day, it collects closed incidents and compiles a summary article. Here, the sequence of steps is static and known in advance — it acts more like an automated pipeline. The agent is highly effective in this role because it generates coherent, analytical text rather than simply moving raw data from A to B. However, this is fundamentally a deterministic process, not autonomous decision-making.

How to Deploy an Agent

A configured AI agent in SimpleOne can be triggered from three different points, depending on the operational context.

1. Workflow Builder

The agent is embedded into a workflow just like any standard action block. Previously, developers had to build subflows to handle non-linear actions within a process. Now, an agent replaces the subflow in situations where the specific steps cannot be rigidly mapped out in advance.

For instance, consider a software development workflow. The stages are standard: requirements gathering, development, code review, testing, documentation, and deployment. However, a single block cannot represent each stage. "Development" involves dozens of Git calls and a separate execution environment; "testing" involves generating and running auto-tests; "documentation" has its own complex logic. A portion of this work is executed outside the platform's runtime on external infrastructure via MCP.

The scenario changes every time: some steps are skipped, others are added, and code reviews run iteratively until the code passes. You cannot build a deterministic subflow for this level of variance.

Therefore, you can replace each stage (or parallelize them) with agent blocks. The workflow isn't assembled from dozens of action blocks, but from agents. You don't need to build a strict sub-process; the agent decides the sequence and selects the tools required to complete its specific stage.

2. API Widget

An agent can be embedded directly into the UI and invoked via API — whether that's a portal widget, an application form, or a messenger chat. The user interacts with a familiar interface and remains unaware of the underlying agent mechanics: they type a request, and under the hood, the agent selects tools, executes actions, and returns the result to that same interface.

The most common implementation is a chat widget. The user types a message in the portal chat, the widget passes it to the agent via API, the agent does the work, and sends the response back. This is a highly flexible option for custom scenarios: you dictate the interface design and the trigger point. It is ideal for quick, ad-hoc tasks not tied to an end-to-end process.

3. Universal Smart Assistant

Providing an out-of-the-box conversational interface on the platform is essentially a specific application of an API call that you don't have to build from scratch. We detail this in the following section.

Agent of Agents: The Conversational Interface

In most corporate environments, the AI assistant exists in a silo separate from business processes — it's a chat interface that answers questions but lacks the permissions to access data or execute actions within the platform. For corporate self-service, we developed an "agent of agents" — a universal intelligent assistant. Behind the chat interface stand multiple agents armed with configured adapters, methods, and instructions.

The user sees a standard chat. Under the hood, the orchestrating agent receives the request, selects the necessary tools from its adapter, and executes actions inside the platform: searching for data, creating records, querying the corporate Knowledge Base, or calling external systems via MCP. The result is seamlessly returned to the dialogue.

How it's configured: An administrator creates a configuration for a specific task or user group. They connect the agent, assign an adapter with the appropriate tools, and enable RAG if needed. When RAG is active, the agent searches for relevant fragments in corporate documents to answer a query, uses them as context for the LLM, and explicitly cites the documents it relied upon. The agent doesn't hallucinate answers; it references concrete materials from your Knowledge Base.

You can maintain multiple configurations simultaneously: one for the IT support team (with access to incidents and the KB), another for financial analysts (with access to reports and platform data), and a third as a general, non-specialized assistant. Users only see the configurations the administrator has explicitly granted them access to.

How this differs from a standard chat widget: While you can build a widget that calls an agent via API for custom scenarios, the Assistant solves a different problem. It provides a ready-to-use interface natively optimized for interacting with agents, complete with dialogue memory and direct integration with corporate knowledge. You don't have to build it, you just configure it for the task.

Furthermore, an agent can create another agent. If an agent has methods for working with platform entities, it can configure a new agent right from the dialogue: the user describes the task, and the assistant assembles an agent to handle it. This is a direct benefit of our unified architecture: an agent interacts with platform entities via methods, and an "agent entity" is no exception.

Soon, we will introduce support for sub-agents: one agent will be able to delegate parts of a task to another directly within the dialogue. This unlocks scenarios where a single user request triggers a cascading chain of specialized agents, each operating within its own adapter and defined area of responsibility.

Case Study: Incident Analyst Agent in IT Support

Let's look at another example of agent activity. This was the first agent Proof of Concept (PoC) the SimpleOne team built on the platform. While it is not yet deployed in production, it perfectly illustrates how an agent operates from initial configuration to final output.

The Agent's Task: Every day, aggregate closed incidents from the platform and compile them into a Knowledge Base article.

The Instruction (Role): "You are an ITSM analyst. You collect incident data and structure it into readable material for the Knowledge Base." It is connected to a Nexus routing to a selected language model.

The Adapter: Contains six methods. The agent autonomously determines the order and selection of these methods at each step:

1. Ask a clarifying question / refine task parameters.
2. Locate the incident table in the platform database.
3. Query the table to fetch closed incidents for a specific period.
4. Analyze data (the language model processes the fetched incidents).
5. Create a draft article for the Knowledge Base.
6. Close the session.

In one test run, the agent retrieved data regarding internet connection incidents and formatted them into a Knowledge Base article. The article was generated automatically, with zero human involvement during the data collection and drafting phases.

Crucially, the agent operates strictly within the permissions of the user who initiated it. It cannot access data the user cannot see, and it performs no actions that aren't explicitly permitted. Every single step is logged: the administrator can see exactly which tools the agent invoked, what data it requested, and what it returned.

The final decision, however, remains with a human (Human-in-the-Loop). Once the article is drafted, an employee reviews it and approves it for publication. The agent automates the heavy lifting — gathering, processing, and drafting — but it does not replace the human where critical judgment and accountability are required.

The entire execution path of the agent is fully traceable step-by-step: which method was called, with what parameters, what the response was, and how the model interpreted the result before moving to the next step. This observability is vital for debugging and refining how the agent makes decisions.

Security and Access Control

Agents on the SimpleOne GenAI platform operate on the bedrock of the platform's existing security architecture. The agent acts on behalf of the user who launched the session: platform permissions are calculated dynamically at the exact moment data is accessed, applied specifically to that user. This guarantees that an agent cannot access data restricted from the user — even if the required method exists in the agent's adapter. Every action is recorded in the platform log: who, when, via which agent, and what was done to the data.

On top of this platform foundation, we add a layer of agent-specific control. For instance, the administrator writes the methods in the adapter. An agent physically cannot execute an action absent from its adapter. It does not invent tools on the fly, nor does it query the database directly. Everything available to the agent is both explicitly defined and permitted. The platform tolerates zero rogue autonomy.

Platform permissions govern access to data and system objects. ACL (Access Control List) criteria at the method level add an extra layer: they dictate whether a user can invoke a specific method via an agent, even if they possess access to the underlying data. For example, you can allow a user to read incidents, but prohibit them from running an agent that mass-updates those incidents.

In short, it’s a three-tier security model:

1. Platform permissions dictate what a user can generally do in the system.
2. Agent access dictates which agents a user is allowed to launch.
3. Method access (In Development) dictates which specific tools an agent is allowed to use during that user's session.

What's Next

We are planning to implement skills for agents — an evolutionary step from basic prompts toward reusable instructions. Currently, an agent receives one overarching instruction. With skills, it will be able to dynamically load the specific skill required for a precise task within a session. This allows administrators to map out highly complex scenarios without bloating the system prompt, offering granular control over agent behavior in varying situations. Our library of out-of-the-box methods and skills will expand, allowing you to assemble an agent for a standard task using pre-built templates rather than writing everything from scratch.

To sum up, we firmly believe that AI agents in an enterprise platform are only as valuable as they are organically embedded into your existing processes and data. The approach we are taking with SimpleOne GenAI is built on this very principle: the agent works with the exact same objects, permissions, and integrations as the rest of the platform. It requires no shadow infrastructure to access corporate data — everything already existing in your system becomes accessible to the agent via methods and adapters.

MCP expands this logic to external systems. Through a unified mechanism, the agent gains access to external tools like Jira, Confluence, monitoring systems, and more. Furthermore, the platform itself can act as an MCP server for external agents. In that scenario, SimpleOne's corporate data and processes seamlessly become part of any broader agent ecosystem your company utilizes. We previously covered this topic in a separate article.