APICA gives Port of Antwerp-Bruges employees one interface in Microsoft Teams while coordinating specialized agents behind it.
2
The nautical agent uses a data catalog to map port terminology to physical SQL data, generate queries, check access rights, and return answers in natural language.
3
The platform combines monitoring, access controls, guardrails, evaluation tests, and user feedback in a continuous improvement loop.
Summary
Pierre Gerardi presents APICA, a multi-agent application intended to become the digital colleague for Port of Antwerp-Bruges employees. Users interact with it through a Teams Copilot, while APICA routes requests to document, service desk, or nautical data agents. The talk spends most of its time on the nautical agent, which translates questions into SQL by using a graph-based data catalog that connects port concepts to physical tables. Before querying, the system checks GDPR sensitivity and the user's access rights. It also restricts which actions agents may take, blocks unsafe inputs, checks outputs for leaked information and unsupported answers, and evaluates a test set for several violation types. Gerardi is direct about the amount of governance required. The system depends on accurate data descriptions and permissions, followed by application development, monitoring, and feedback-driven changes. He says the data catalog made a large difference because port terminology is unfamiliar to a general language model.
APICA is intended to become one interface for the port's smart systems
Port of Antwerp-Bruges wants a digital nervous system for managing the port remotely. Its smart technology ecosystem includes a digital twin, APICA Chat, an optimization planner, smart-camera capabilities, and a navigator for vessel routes. APICA Chat is intended to become the interface for this whole system. A user could report that a tugboat crew member is sick, and APICA would route the request to the planner, then return the updated planning through the chat interface.
A single entry point reduces the maintenance and discovery burden
The port required one point of entry for its complex agent system. Creating a separate interface for every agent would increase maintenance work and make it harder for users to find the right interface. The team also created a common agent template so agents could be maintained consistently and connected more easily. Reusable tasks are shared across agents when their work overlaps or differs only slightly.
The platform routes questions to specialized agents
APICA runs as a Teams Copilot that employees can add to their team space. The initial agents include one for talking to documents, a service desk assistant that uses human resources and ICT data, and a nautical-data agent. The service desk assistant can escalate an issue to the appropriate ICT worker. The nautical agent translates a question into SQL, executes the query, and returns the answer.
A data catalog gives the agents the port's vocabulary and data map
The data catalog describes business-specific terms, links related concepts, and maps those concepts to physical data. This gives an agent a route through the internal data without requiring every prompt to list available sources. For a question about seagoing vessels arriving yesterday, the system connects concepts such as arrival journey and vessel, finds the path between them, locates the relevant journey and vessel SQL tables, and uses validated queries from business analysts to formulate and execute the answer.
Access checks happen before the agent can answer or act
The system checks whether selected concepts are GDPR-sensitive and whether the user can access the physical data behind them. If the requested information is restricted, APICA tells the user it cannot answer. The agent also has its own action restrictions. Deleting data is never made available to an agent, while actions such as creating a service desk ticket can be allowed by passing the user's rights to the agent.
Guardrails cover inputs, outputs, and factual support
Input guardrails block questions the agents should not handle, such as asking how to smuggle drugs into the port. Output guardrails are intended to prevent internal information from being exposed if parts of the system are later opened to external users. The system also compares an answer with its references to check whether the response is supported.
Evaluation and feedback feed a continuous improvement loop
The team created a test set and scores the application for input violations, output violations, factual consistency, and data-access violations. They simulate test cases, inspect where improvements are needed, and collect live user feedback through thumbs-up, thumbs-down, and comments. Gerardi describes the broader process as a loop from data governance to application development, publication, monitoring, and further improvement.
Port-specific descriptions improved the system substantially
In the discussion, Gerardi says the biggest improvement came from using the data catalog. The port uses terminology that a general language model does not typically know, so describing the concepts in the language used at the port helped the system. His practical advice is to first examine the real use case and the data, then check whether the data has useful descriptions before focusing on the agent itself.
"The biggest success for us really became when we used the data catalogues because they use some specific language at the port which is not typically known by an LLM."18:27
Who should watch
You are building several internal agents and need one user-facing entry point instead of a collection of disconnected tools.
Your text-to-SQL system needs to understand organization-specific terms, table relationships, permissions, and sensitive data.
You need practical controls for agent actions, unsafe requests, output leakage, evaluation, and feedback from internal users.
