Mendix Agent and MCP development
AI and DX
Conversational AI connected to business systems running on Mendix. Multi-agent conversation flow, MCP server and client, and integration with the existing systems.
Context and problem
- The hard part was scope, not the model: what may be asked, how far the agent may act, and which data it may read to answer.
- Added to systems already in production. Authentication had to follow what existed, and features had to sit on top without changing screens or the data model.
- Scope is separated from the partner’s. Building the ontology platform and connecting external source data was their work.
Role, period, and scope
System map
Conversation surface
The conversational screens where people ask and read results, and the state handling underneath them.
Agent orchestration
The layer that decides which agent handles a request and turns tool results back into conversation.
MCP tool layer
The definitions and permission boundaries of the tools an agent actually calls, each kept deliberately narrow.
Knowledge access
The path that reads graph-based retrieval and relational data together to ground an answer.
Enterprise integration boundary
The integration points that let a new flow attach without disturbing existing authentication, domain logic, or viewers.
Decisions that mattered
Design the multi-agent conversation experience
Team work
- Problem
- With one agent handling everything, answers got long and users had no way to see what the answer was based on.
- Judgment
- Route by request type to a responsible agent, and show the progress and the tools called on screen.
- Action
- Requests are routed to an agent by type, and the screen shows progress and the tools that were called inside the conversation itself.
- Verification
- I sent the same question through several paths to check that the intended agent was selected and that intermediate state reached the user without gaps.
MCP servers and clients, and the Agent work inside Mendix
Individual work
- Problem
- The more an agent could do, the more the question of what it may and may not call was scattered through the code.
- Judgment
- Defining tools at the protocol level keeps permissions and responsibility inside the tool definition.
- Action
- I connected MCP servers and clients and defined the tools the Agent uses inside Mendix, keeping each tool narrow enough to reduce the number of exceptional cases.
- Verification
- I called each tool from accounts with different permissions to confirm that requests which should be refused were refused, and that a failure does not stall the conversation.
A Work Agent spanning several microflows
Individual work
- Problem
- Finishing a single piece of work meant calling several microflows in order, and that order lived in somebody’s head.
- Judgment
- The agent holds the call order rather than the person doing the job.
- Action
- I designed and built a Work Agent that groups several microflows into one unit of work, and made partial progress visible when a step fails midway.
- Verification
- I forced failures at intermediate steps and retried, checking that the same work was not performed twice.
Integrate without changing what already runs
Individual work
- Problem
- Attaching the new flow meant touching authentication, domain logic, and viewers that were already in use and could not be paused.
- Judgment
- Adding an integration point in front of the existing components carries less risk than changing them.
- Action
- I attached a path that reads graph-based retrieval alongside relational data and connected an on-premises language model. Problems arising in Teamcenter integration, OIDC authentication, Java Action, and the 3D viewer were each traced to a cause and resolved.
- Verification
- I forced a failure per integration target to confirm the existing screens kept working, and compared the authentication path against the policy already in force.
What the partner delivered
Partner-built (not my work)
- Problem
- Knowledge access depended on an ontology platform and on connections to external source data, and that part was not mine to build.
- Judgment
- Partner-built work is not written up as mine, and the boundary is marked the same way in the public documents and here.
- Action
- The ontology platform and the external source-data connections were built by a partner. I owned the integration on the consuming side and the tool definitions.
- Verification
- I marked the boundary the same way in the public write-up as in the internal record, and re-read the text for any sentence that could be taken as claiming the partner’s work.
Implementation evidence
Client screens are not published. The diagram sets out the structure and the boundary of responsibility.
Measurable outcomes
- Twenty-eight UI screens designed
- The volume of screens needed once the product has to carry a workflow rather than end at a single reply.
- Twenty-eight MCP tools designed
- The scope that lets an agent actually execute something instead of only describing it.
Reflection
- Scope, not model choice, took the longest. The narrower the agent’s permissions, the more the results could be trusted.
- The more a piece of work is split with a partner, the more the boundary is worth writing down.