Governed automation with AI agents and MCP

Throughout 2025, corporate use of generative AI is gradually shifting from information retrieval and summarization to performing multi-step tasks. New agent platforms allow language models to utilize external tools, access corporate systems, and coordinate information processes. The development of Model Context Protocol (MCP), agent SDKs, and evaluation tools is creating opportunities for standardizing such integrations. However, along with new capabilities comes a fundamental challenge: ensuring that AI operates within corporate authority, does not violate access rules, and does not create uncontrolled changes in ERP, CRM, MDM, and electronic document management systems.

October 2025: Agent Systems Transition from Experiments to Applied Infrastructure

Throughout 2024, one of the most common corporate scenarios for generative AI was document search using Retrieval-Augmented Generation. Such systems allow employees to ask questions in natural language and receive answers based on the corporate knowledge base.

However, the vast majority of traditional RAG solutions perform an informational function.

They find regulations, explain documents, or help navigate corporate knowledge.

In 2025, the situation began to change. Developers gained more capabilities to create systems that not only generate responses but also invoke software tools.

On May 21, 2025, OpenAI announced support for Model Context Protocol remote servers in Responses API. This allowed for the standardization of part of the integrations between language models and external services without the need to develop a separate connection mechanism for each source.

On June 18, a new MCP specification was released, which enhanced support for structured tool results, OAuth authorization, and mechanisms for obtaining additional data from users.

On August 7, OpenAI introduced GPT-5 with new capabilities for working with tools and complex tasks, expanding the technological foundation for agent applications.

On October 6th at OpenAI DevDay, AgentKit was introduced – a toolkit for designing, deploying, and evaluating agent systems.

Its components include Agent Builder, ChatKit, Connector Registry, and enhanced Evals capabilities.

These developments do not mean that agent automation has already become fully mature or secure by default. On the contrary, the advancement of technologies makes the need for architectural control more apparent.

For enterprise IT, the main challenge lies in transitioning from an informational interface to a system that is potentially capable of modifying data.

For example, a user might ask an agent:

“Find all overdue invoices, prepare reminders for clients, and update statuses in CRM.”

To accomplish such a task, it’s not enough to just find information. It is necessary to verify financial data, identify counterparties, determine permissible actions, generate notifications, and correctly change statuses.

Each stage has its own requirements for reliability, security, and accountability.

The main question for October 2025: how to transform AI agent capabilities into a manageable corporate service without creating a new source of operational risks?

2. RAG, Tool Calling, and AI Agents: Three Different Levels of Automation

For a correct architecture, it is necessary to separate three types of systems.

RAG — The Information Layer

The system receives a request, finds relevant sources, and generates a response. For example, it explains the procurement approval process based on corporate regulations.

The main risk is an incorrect or incomplete response.

Tool Calling — Applied Integration

The language model can form a structured call to a defined function. For example, to get the remaining stock via API.

The main risk is incorrect call parameters or violation of access rights.

AI Agent — Action Sequence Management

The system can select the next tools based on the results of previous steps. For example, find a product, check suppliers, form a request, and pass it for approval.

The main risks are uncontrolled action sequences, repeated execution, exceeding authority, and incorrect recovery from errors.

Comparison

An enterprise is not required to implement a full-fledged agent for every task. If a process has a clear and unchanging sequence, traditional automation may be simpler, cheaper, and more reliable.

LLMs are best applied where they add real value: interpreting natural language, working with unstructured documents, or assisting in action selection under complex conditions.

3. Model Context Protocol: Standardized Access to Corporate Tools

MCP was introduced at the end of 2024 as an open protocol for AI applications to interact with external sources and tools. Its development in 2025 made the protocol an important direction for corporate integration.

The specification dated June 18, 2025, covers, among other things, instrument exchange mechanisms, structured results, OAuth authorization, and additional methods for user interaction.

As of October 30, 2025, this particular version remains the currently published version of the specification. The next version is scheduled for November and should not yet be used as the current one.

MCP can simplify the integration of enterprise AI with various systems.

For example, an enterprise can create separate servers for:

• searching corporate documentation;
• obtaining DWH metrics;
• reading MDM directories;
• working with CRM;
• preparing requests in BPM;
• obtaining integration statuses;
• working with the internal Data Catalog.

However, MCP does not replace corporate authorization. The presence of a tool in the list of available functions does not mean that the user has the right to perform all its actions.

Therefore, the MCP server must implement its own mechanisms for checking authorizations and business restrictions.

4. MCP Architecture in a Corporate Environment

For large enterprises, it is advisable to use a layer of controlled services between the agent and corporate systems.

Logical Schema

Corporate User

Identity · Role · Business Context

AI Agent / LLM Application

Query understanding · tool selection · step coordination

MCP Client / Tool Gateway

Challenges · policies · limits · confirmations · audit

• MCP Read Services
• Data Catalog
• DWH Metrics
• RAG / SED

MDM Lookup

• MCP Operation Services
• CRM Updates
• BPM Requests
• Draft Documents
• Controlled Actions

Corporate Systems

ERP · CRM · MDM · DWH · BPM · ECM

It is critically important to separate read tools from data modification tools. For example, the get_customer_status function can be relatively safe provided that permissions are checked.

The update_customer_bank_details function carries a completely different level of risk.

It requires special rules, and in many cases, a prohibition of direct agent execution.

5. OAuth and Access Control

During corporate integration, it is necessary to distinguish between the identity of the agent, the user, and the service on whose behalf the request is being made.

For example, an agent operates through an MCP server that has technical access to the CRM. This does not mean that all agents’ users should receive the same permissions in the CRM.

The correct architecture should define on whose behalf an action is performed and what permissions are allowed. For this purpose, OAuth, short-lived tokens, scopes, and server-side authorization can be used.

However, it is necessary to avoid the insecure transfer of tokens between different systems without verifying their intended use.

For instance, a token issued for one service should not be automatically used for another API unless it aligns with its audience and access rules.

Authorization Matrix

It is especially important that access rights are not determined solely by the language model’s prompt.

Authorization must be performed by programmatic mechanisms that are independent of the generated text.

6. AgentKit and the Development of Agent Orchestration

On October 6, 2025, OpenAI introduced AgentKit. This is a set of tools for developing, deploying, and evaluating agent systems.

One of its components is Agent Builder — a visual environment for designing agent processes. ChatKit is designed for embedding relevant conversational interfaces into application systems.

Connector Registry is focused on centralized management of connections to sources and tools.

Advanced Evals capabilities allow evaluating agent behavior on test sets and analyzing execution traces.

This is an important trend for enterprise IT. An agent system is gradually ceasing to be a set of individual API calls hardcoded by the developer.

Tools for version control of agent processes, verification of results, and reuse of integration components are emerging.

However, it is necessary to distinguish between the technological availability of new tools and their maturity for critical business operations. Not every new feature should be immediately used in the production ERP.

For financial or legally significant actions, it is advisable to maintain a controlled BPM level.

7. BPM and Agent Orchestration: Who is Responsible for Process State

One of the main challenges of agent systems is maintaining long-term state. For example, an agent prepared a contract and sent it for approval.

Two days later, the manager approved the document. After this, the next stage needs to be executed.

If the sole source of state is the textual interaction history with an LLM, such a system can be unreliable.

The corporate process must have a separate authoritative state.

A BPM Engine can be used for this purpose.

LLM performs information tasks.

BPM manages sequence, responsible parties, timers, and transitions.

Example of function distribution

This separation reduces the risk of uncontrolled states. For example, if the LLM is temporarily unavailable, the BPM can save the process and resume it later.

And if the ERP rejected the operation, the agent should not inform the user that the document was successfully created.

8. Idempotency and Re-execution of Tools

Agent systems can re-invoke tools. For example, after a network loss, the agent did not receive the result of the request creation.

It does not know whether the server performed the corresponding operation. If the call is repeated without control, duplication of the document is possible.

Therefore, idempotency must be used for operational tools.

Example of a control table

CREATE TABLE tool_execution_log (
    operation_id UUID PRIMARY KEY,
    actor_id VARCHAR(100) NOT NULL,
    tool_name VARCHAR(100) NOT NULL,
    status VARCHAR(30) NOT NULL,
    request_hash VARCHAR(128),
    external_reference VARCHAR(100),
    created_at TIMESTAMPTZ NOT NULL
        DEFAULT CURRENT_TIMESTAMP,
    completed_at TIMESTAMPTZ
);

Each logical operation receives a stable operation_id. During a repeated call, the server checks if a corresponding operation already exists.

If it is completed, the system returns the previously recorded result. If it is in an indeterminate state, the authoritative operating system needs to be checked.

It is important that the table itself does not guarantee exactly-once execution. If an external ERP created a document but the local journal has not yet received confirmation, a reconciliation mechanism is needed.

Therefore, it is advisable to use idempotent APIs, business keys, or Transactional Outbox where the architecture allows.

9. Prompt Injection and Dangerous Tool Outputs

For enterprise agents, instructions coming from untrusted sources pose a particular danger. For example, an agent analyzes a supplier’s email.

The text of the email contains a request to change the bank details in the corporate system. The language model may mistakenly perceive it as a valid instruction.

However, the supplier’s email is data, not an authoritative source. Therefore, the enterprise agent must distinguish between:

• trusted application instructions;
• authenticated user request;
• results from external tools;
• third-party documents and messages.

It is especially important not to allow text from RAG or MCP to change access policy.

Protection Levels

For critical operations, simply adding the instruction “do not perform dangerous actions” to the prompt is insufficient.

Restrictions must be implemented independently of the model’s behavior.

10. Human-in-the-Loop: Meaningful Control

Humans must confirm operations that have significant business implications. However, not every confirmation is equally useful.

For example, an “Approve” button without a description of the future action does not provide adequate control. The user should see:

• what exactly will be executed;
• what data will be changed;
• what sources were used;
• what checks have been passed;
• what the possible consequences are;
• whether the operation can be canceled.

For financial and legal operations, the confirmation must comply with corporate authority.

Levels of Human Participation

This segregation allows for avoiding unnecessary approvals where they are not needed, while ensuring control over critical operations.

11. Corporate Data Governance for Agents

An agent application can access many information systems. For example, to prepare a purchase request, it requires data from ERP, MDM, and corporate document management.

However, this does not mean that the agent should have full access to the relevant databases. An access policy needs to be defined at the information product level.

Data Governance Matrix

Particular attention should be paid to agent call logs. They may contain personal, financial, or confidential data.

Therefore, logging should be sufficient for auditing but should not create unnecessary uncontrolled duplication of information.

12. Evals: Why Actions, Not Just Responses, Need Testing

For RAG, one of the important metrics is the correctness of the response and the relevance of the sources. For an agent system, the sequence of actions must also be evaluated.

For example, an agent might provide the user with a correct final answer, but during execution, it might make an unnecessary API call or access information that the user is not authorized to access. Therefore, the quality of an agent system cannot be determined solely by its textual output.

It is necessary to analyze:

• tool selection;
• correctness of parameters;
• compliance with permissions;
• sequence of operations;
• Retries;
• Business outcomes;
• Execution time;
• Costs.

AgentKit, introduced in October 2025, develops evaluation tools, including trace grading and test set manipulation, which can help analyze agent processes.

Agent Automation KPIs

To evaluate, not only positive examples are needed.

The test set should include unavailable APIs, incorrect details, conflicting data, lack of permissions, and Prompt Injection.

October 2025 Technology Stack

As of October 30, 2025, new technological capabilities are available for enterprises for agent automation and corporate integration.

Apache Kafka 4.1.0 was released in early September. It introduces a preview of Queues for Kafka, which is not yet recommended as a fully production-ready mechanism as of this date.

Apache Airflow 3.1.1 was released on October 27, 2025.

Apache Iceberg 1.10.0 became available in September 2025, and Spark 4.0.1 in early September. It is important not to postpone later features of these platforms to October 2025.

For example, the MCP specification from November 2025 has not yet been published as of the date of this article. Similarly, individual agent orchestration mechanisms remain new and require operational testing.

14. Practical Scenario: Accounts Receivable Control Agent

Let’s consider a hypothetical Ukrainian distribution company.

The company uses ERP, CRM, electronic document management, and BPM. The finance department regularly generates a list of overdue invoices.

Managers manually check clients, search for contracts, and prepare reminders.

Management is considering agent-based automation.

Stage 1. Defining Allowed Functions

The agent is authorized to read approved financial metrics and create draft messages.

Independent payment processing, changing bank details, and debt write-offs are prohibited.

Stage 2. Data Governance

Available clients, personal data categories, and information usage rules are defined.

Stage 3. MCP Integrations

Controlled services are created to retrieve overdue invoices, search for the client, and find the contract.

Stage 4. Analysis

LLM can help classify the situation and prepare a reminder option.

Stage 5. Verification

The application layer verifies that the invoice is indeed overdue, the amount matches the ERP, and the client is available to a specific manager.

Stage 6. Human-in-the-Loop

The manager reviews the prepared message.

Stage 7. BPM

After confirmation, the process creates a task or sends a message through the agreed corporate channel.

Stage 8. CRM

The interaction status is updated after confirmation of the actual execution of the corresponding operation.

Stage 9. Audit

Document identifiers, actual calls, and results are stored.

Stage 10. Evaluation

Time costs, error counts, and compliance with business rules are compared.

This scenario is hypothetical and does not describe a project completed by Intecracy Group companies.

15. Economic Model of Agent Automation

Let’s consider a hypothetical company that processes 3,000 invoices monthly. For 900 of them, additional verification or customer notification is required.

Before automation, an employee spends an average of 10 minutes on the corresponding operation.

After the implementation of the agent assistant, manual verification takes four minutes.

Conditional Calculation

If the conditional full cost of working time is 20 euros per hour, the cost of the freed-up time amounts to 1,800 euros per month. However, this does not mean automatic monetary savings.

Costs for LLM, MCP infrastructure, checks, monitoring, and support must be considered.

Additionally, the freed-up time can be used for other operations.

Therefore, it is necessary to evaluate efficiency through Total Cost of Ownership and business results.

16. 120-Day Implementation Roadmap

It is advisable for enterprises to start with processes where the agent prepares information but does not perform irreversible operations.

Only after confirming stability can the expansion of powers be considered.

17. KPI, Control, and Production Readiness

For a corporate agent, it is insufficient to measure the number of processed messages.

It is necessary to determine if it performs a specific business function without violating established rules.

Control Matrix

It is especially important not to consider a one-time successful test as sufficient. After updating the model, prompts, tools, or corporate APIs, re-validation is necessary.

This is because changing one component can affect the behavior of the entire agent process.

18. Risks and Common Errors

Excessive autonomy. Not every operation should be performed without confirmation. Confusion between MCP and authorization. The protocol does not replace corporate rights.

Shared privileged accounts. The agent should not be granted unrestricted technical access.

Lack of BPM. Long-running business processes require a reliable state and defined transitions. Insufficient idempotency. Repeated calls can create duplicates.

Incorrect handling of external data. Prompt Injection can come through documents or tool results. Insufficient LLM validation. A correct final answer does not guarantee the correctness of all intermediate actions.

Lack of Data Lineage. It is difficult to determine which sources were used for the solution.

Excessive logging of confidential information. Auditing should be sufficient but proportionate.

Uncontrolled costs. An agent may make significantly more calls than expected.

Premature modernization. New agent tools require testing before use in critical processes.

19. Intecracy Group Competencies

The development of managed agent automation requires interaction between specialists in data management, system integration, business processes, and infrastructure. Data Management IG (dmig.com.ua) specializes in ETL, MDM, Data Quality, Data Warehouse, Data Lake, Data Governance, and corporate analytics. These competencies can form the information foundation for agent systems: authoritative sources, consistent directories, quality control, metadata, and rules for using corporate information resources.

IQusion IT (iqusion.com) represents system integration, electronic document management, Business Process Management, and business process automation. Relevant competencies are important for organizing controlled operations, routing approvals, application APIs, and managing long-term processes. Softline IT (softline.kiev.ua) works in the area of server and network infrastructure, storage systems, and infrastructure projects. These areas can provide the technological basis for MCP services, application gateways, logging, and corporate information platforms.

SL Global Service (sgs4business.com) specializes in cloud integration, virtualization, and hybrid infrastructure. These technologies allow for considering hybrid deployment of agent services, corporate LLMs, and related computing resources.

The combination of these specializations creates a foundation for a comprehensive approach to enterprise agent automation, but does not imply the existence of specific off-the-shelf products or proven implemented agent systems.

An enterprise agent must be part of a managed information architecture

October 2025 demonstrates significant development in agent automation tools. The Model Context Protocol creates a standardized framework for connecting language models to information sources and software functions.

AgentKit and other agent development platforms are advancing tools for design, evaluation, and operation.

New language models are becoming more suitable for performing complex multi-step tasks. However, technological capabilities do not eliminate the need for corporate governance.

On the contrary, agent systems require even clearer delineation of responsibilities. An LLM can interpret a request and suggest the next action.

MCP provides a standardized interface for invoking the appropriate tool. However, the right to perform an operation should be determined by corporate authorization mechanisms.

ERP remains the authoritative source for financial and operational transactions. MDM supports master data.

BPM manages long-term processes and approvals.

Data Governance defines which data can be used and who is responsible for its quality. The ability to restore processes after failures is particularly important.

The agent system should not create duplicate orders or messages simply because it did not receive confirmation from an external API. Therefore, idempotency, logging, and state control remain as important as the quality of the language model.

For Ukrainian enterprises operating in wartime conditions, agent automation can help reduce manual workload and support distributed teams. However, it should be implemented gradually, taking into account real business risks and operational capabilities.

October 2025 Key Takeaway: The maturity of an enterprise agent system is determined not by the number of tools it can invoke, but by the level of control, reproducibility, and accountability for executed operations. For the Data Management IG, this means a new application of traditional enterprise data management competencies.

ETL, MDM, Data Quality, Data Warehouse, and Data Governance provide a trustworthy information foundation, without which agent automation cannot be reliable.

It is the combination of new AI tools with a mature enterprise architecture that allows a technological experiment to be transformed into a practical business management tool.