«الذكاء الاصطناعي يعطيني معلومة» و«الذكاء الاصطناعي يطلق الإجراء» ليسا المنتج نفسه.
ربط الوكيل بواجهات API وقواعد بياناتكم وبرمجياتكم القطاعية والخدمات الخارجية. إنها اللحظة التي يكفّ فيها الذكاء الاصطناعي عن كونه أداة إضافية ليصبح طبقة التفاعل مع نظام معلوماتكم.
- REST وOpenAPI وMCP
- صلاحيات موروثة من نظامكم
- إجراءات مسجَّلة
Why pilots stop at the answer
Moving from “answer” to “act” raises three technical questions most projects did not anticipate.
There is no API
The business tool is twenty years old and does not open up. All the project's value depends on writing into it, and nobody costed that work at the start.
Rights only exist in the database
The agent connects with a service account that sees everything. Technically it works. In an audit it is indefensible, and the project dies at the security committee.
Nothing is reversible
An action triggered in error has neither a usable trace nor a correction path. Management refuses write access, and the pilot stays read-only forever.
How you wire an agent into a real information system
Order matters: security and traceability come before the first write, not after the first incident.
Mapping the systems
Which tools hold which data, which expose an API, which will need one built. This step produces the list of actions genuinely possible today, and a cost for those that require development.
Defining the tool contract
Every action the agent will be able to trigger is described explicitly: inputs, outputs, effects, failure conditions. The agent can only call what is on that list — the perimeter is declared, not inferred.
Propagating rights
The agent acts with the rights of the person who launched it, never with an all-powerful technical account. A sales rep does not trigger an HR-restricted action, even by asking the agent explicitly.
Guardrails and sign-off
Thresholds above which human sign-off is required, forbidden-action lists, volume and cost limits per run. Irreversible actions never go out without confirmation.
Logging and reversibility
Every call is recorded with its author, parameters and result. Where the action allows it, the correction path is designed in — that is what makes write access acceptable at the security committee.
What we connect to
REST and OpenAPI
From your existing Swagger specification, without writing one connector per service.
MCP
Model Context Protocol, where your services expose it or where we adapt them to.
Databases
Controlled reads and writes, with a declared perimeter and logged queries.
CRM and ERP
Creating and updating records, with the originating user's rights.
Internal tools with no API
Where no API exists, the software pole builds one. That is often the real project.
External services
Messaging, storage, signature, payment, sector services, within the limits you set.
The technical guarantees
These are what get a project through the security committee, not the model's performance.
- Declared perimeter
- The agent can only call explicitly authorised tools, described by their contract.
- Propagated rights
- Every call is authenticated with the originating user's identity.
- Human sign-off
- Configurable thresholds above which an action requires confirmation.
- Complete log
- Author, timestamp, parameters, result — readable by a non-technical person.
- Execution limits
- Volume, frequency and cost caps per run, to prevent runaway behaviour.
- Test environment
- Write actions are validated on a separate environment before production.
Three levels of write access
Agents read the CRM but do not write to it. Every update stays manual and happens late.
Tool contract on the authorised CRM objects, rights propagated from the user, human sign-off above a defined amount.
The agent creates and updates opportunities live, with a readable log and a correction path.
A legacy business tool does not open up. Any automation implies human re-keying.
The software pole builds an API around the existing tool, then the agent is wired into it.
The tool becomes integrable without being replaced, and automation becomes possible without a migration project.
The assistant answers correctly but cannot trigger anything: every action goes through a human who retypes it.
Tier-1 actions authorised — opening a ticket, resending a document, updating contact details — with logging and thresholds.
Simple requests are handled end to end, and humans focus on what needs judgement.
أسئلة شائعة
The software pole builds one around the existing tool. That is frequently the real project, and it is costed at scoping rather than discovered mid-way.
No. It acts with the rights of the person who launched it. That is an architectural choice, and it is what makes write access acceptable at the security committee.
Every call is logged with its parameters. Where the action allows it, the correction path is designed in. Where it does not, the action goes through prior human sign-off.
No. REST with an OpenAPI specification works perfectly well. MCP simplifies tool description where your services already expose it.
There is no technical limit, but there is a common-sense one: every connected tool is a tool to maintain. We start with the ones carrying the value.
No. The deployment can be entirely internal, with the agent running inside your network without external exposure.
ما لا يفعله هذا الحل
We do not let an agent single-handedly trigger an irreversible financial, contractual or legal action. Those steps go through human sign-off, by design, even when the client asks for the opposite. And where a tool exposes no API, we do not resort to screen automation: it is fragile, it breaks on the first update, and it defers the problem instead of solving it.
Which action should your AI be able to trigger?
Name one. We will tell you what it implies on the API side, the rights side and the traceability side — and whether the path already exists.