The interfaces an organisation integrates against, exposed to models as typed tools with bounded permissions.
Most of what is sold as an agent is a model with a prompt and an API key. It demonstrates well and it is not something an organisation can be responsible for, because nobody can say in advance what it is permitted to do.
The useful version starts one layer lower: with the APIs the organisation actually integrates against, and with an explicit statement of what a model may call.
Exposing capability to a model over MCP as typed tools is not a convenience. It is what turns an open-ended request into a bounded set of operations with declared inputs, declared effects and a place to enforce authorisation.
The design question is not what the model can do, it is what the tool surface allows. Everything the surface does not expose is not a policy the model has to respect; it is an action that does not exist.
Retrieval that cites its sources is the difference between an answer somebody can check and an answer somebody has to trust. In a regulated organisation that distinction decides whether the system is usable at all.
The same reasoning bounds the action side: an agent may read widely and act narrowly, and anything with a consequence that is difficult to reverse goes through a person.
Whether to use a hosted model or an open-source one is not a preference. It follows from what the data is, where it may go and what the organisation has to be able to demonstrate afterwards. Sometimes the answer is that the better model is the one you cannot use.
The tool surfaces, the systems behind them, the organisation or the data. Described at a high level under NDA.
Work carried out under NDA. This page describes the engineering, not the employer. No employer names, internal architectures, client details or proprietary systems appear anywhere on this site, and none will be added.