AI Agent Platform

An AI agent is a program that receives a goal, decides on its own which steps to take, and calls external systems to execute them. One agent can be written in a few days and almost always works in a demo. Problems begin when there is more than one agent, they live longer than a single session, and they touch production systems.

An AI agent platform is the shared layer that handles everything around the model: starting and stopping the agent, its memory, access to data and tools, the action log, permissions, and the points where a human confirms the decision. In this setup, the model is replaceable, the platform is not.

It is important not to confuse three different things. Framework (LangGraph, CrewAI) - a library from which a developer assembles an agent in code. Visual builder (Dify, n8n, Flowise) - an environment where a workflow is assembled with a mouse and immediately gets a UI and API. Platform what remains when you have dozens of agents: a single registry, shared access to tools, observability, and governance. The first two often grow into the third, but do not become it automatically.

Gartner's forecast that more than 40% of agent projects will be shut down is not about the models. Operations break down, and they do so predictably.

Agent sprawl. Departments launch their own agents independently. Six months later, the company has two dozen of them, half have no owner, and no one can say which ones access the production database or with what permissions.

Loss of context between handoffs. An agent hands off a task to another agent, and with it the history is lost: why the decision was made, what has already been checked, what is forbidden. According to 2026 data, about 22% of production deployments already coordinate three or more agents - meaning handoff has become the norm, not the exception.

No human in the loop for high-cost actions. As long as the agent is only reading, there is no risk. Once it starts sending documents, changing prices, or writing to an accounting system, you need a point where an employee confirms the decision and an audit trail to investigate the incident later.

Nothing to show in a review. Without tracing, there is no answer to the question of why the agent did it. That stops adoption faster than any technical limitation.

Hermes Agent from Nous Research stands out even among major platforms: it has an MIT license, an open repository, and the largest community in the selection. It is built around a different idea from enterprise orchestrators. The agent lives where people already communicate — Telegram, Discord, Slack, WhatsApp, Signal, email, and the terminal — builds memory of the user’s projects, turns recurring actions into skills, plans tasks from plain-language instructions, and runs code in a sandbox: locally, in Docker, over SSH, or in the cloud.

The practical conclusion for a company is twofold. Hermes should not become the core of an enterprise process: it is designed for one person, and model access comes through a developer subscription — exactly the dependency an internal architecture should usually eliminate. But two of its ideas are worth adopting in any enterprise project. First, the agent appears in the channel where the employee already works instead of requiring another tab; this directly affects adoption. Second, memory and skills accumulate automatically, so over time the agent needs fewer explanations rather than more configuration.

Huawei is asked about more than the others, and the answer in 2026 is clear. The company has a commercial agent platform Huawei Cloud AgentArts and its open edition - openJiuwenreleased under the Apache 2.0 license. This is not a stripped-down demo version: the open edition shares more than 90% of its core with the commercial one, so it can be used for production, not just experiments. It is developed jointly by Huawei's research labs, the cloud division, and the Xiaoyi assistant team.

It has two layers that can be used separately. agent-core An SDK for developing, running, and fine-tuning an agent. JiuwenSwarm An add-on for agent swarms, where a task is handled by a group rather than a single worker. Separately, in March 2026 Huawei open-sourced A2A-T, an industry-specific extension of the A2A protocol for telecom, signaling a focus on compatibility rather than a closed stack.

Three more open projects belong on the list and are rarely mentioned in CIS-language reviews, although all of their licenses allow commercial use:

Coze Studio A visual agent-building platform from ByteDance, open-sourced in July 2025 together with the Coze Loop evaluation system. Its closest functional analogue is Dify; the notable difference is the low hardware bar: local deployment is stated to need 2 cores and 4 GB of memory, so a pilot can run on a standard VM.

Eino A Go orchestration framework from the same team. The practical value is simple: if the platform team writes in Go, the agent layer no longer has to be the only Python service that nobody can maintain.

AgentScope A multi-agent framework from Alibaba's Tongyi lab; version 1.0 was released in September 2025. Its strength is observability tooling for how agents communicate with one another, which is exactly where multi-agent scenarios usually break down.

The overall conclusion for the Asian stack is the same as for the Western one: the licenses are permissive, the entry barrier is low, and the differences between projects are not in the feature list, but in whether you have a team that speaks the relevant language and are willing to read documentation that sometimes exists only in Chinese.

The two standards address different tasks and are used together in 2026 projects.

MCP describes how an agent gets access to a tool or data source. This is the vertical agent-to-system connection. By February 2026, the protocol SDKs were being downloaded about 97 million times per month, all major model providers had adopted it, and API gateway vendors were embedding MCP support into their products.

A2A describes how agents coordinate with each other and hand off tasks - the horizontal connection. As of April 2026, more than 150 organizations were using the protocol in production. In March 2026, Huawei announced the open sourcing of A2A-T, an industry extension for telecom.

The practical conclusion is simple: tools connect through MCP, and task handoff between agents happens through A2A. A platform that supports neither will lock you in at the integration layer.

There is no need to build your own agent platform today: the orchestration layer is widely available and free, while competitive differentiation has shifted to integrations, permissions, and acceptance testing. The question is which engine to use as the foundation so you do not have to rewrite everything in two years.

For processes involving approvals, signatures, and data requirements, it is sensible to use as the core LangGraph. The reason is not popularity but its execution model: the process is described as a state graph with checkpoints, so the agent can survive failures and resume from the same point, stop and wait for a human decision, and leave a reproducible trace of what it did and why. Version 1.0 was released in October 2025 with a commitment to preserve compatibility until 2.0; the MIT license allows you to build a client product, and the engine is not tied to a model provider: to meet personal-data requirements, teams can connect both open models on their own infrastructure and services hosted in CIS data centers.

A candid caveat about this choice. The promise of “no breaking changes” has already proved not to be absolute: in autumn 2025, the related `langgraph-prebuilt` package introduced incompatibility through a transitive dependency. Production versions are therefore pinned strictly, and updates go through regression testing—as with any other library the process depends on.

When another core is a better choice. If the company operates in the .NET ecosystem and all development is done there, Microsoft Agent Framework will provide a shorter path and a commitment to long-term support. If the goal is to test a hypothesis quickly with analysts rather than developers, a visual platform will be faster: Dify or Coze Studio. If the platform team writes in Go, Eino will eliminate the only Python service in the landscape. The general rule is simple: visual builders work well while the scenario fits on one screen; as soon as branching, rollbacks, and signatures appear, an engine with an explicit state model wins.

KT.Team deploys the listed open platforms within the customer's environment: we set up orchestration, connect enterprise sources through RAG and MCP, put in place a model access gateway with request logging, and configure tracing and permissions before the agent gets write access.

The working approach is the same as in our other AI projects: we take one process, bring it to a working state and acceptance, and only then expand the scope. Details on related topics are on the pages LLM gateway, MCP, n8n and an enterprise knowledge base on RAG. Federal Law GDPR requirements are covered separately: compliance with Federal Law GDPR and protection of personal data information systems.

If the platform has already been chosen and you need a working agent for a specific process, the workflow, timeline, and indicative pricing are provided on the page AI agent development.