The problem
The AI lives in a separate tab. Someone copies the input in, copies the output out, and makes the actual update by hand.
The integration exists as a script on a laptop. There is no authentication, no retry, no logging and no owner.
The model can write to a system of record, but nobody has defined what it is allowed to change and what needs approval.
An API or model update breaks the workflow silently, and the first signal is a customer complaint.
What you get
Outcomes
- The AI step lives inside the existing workflow instead of beside it.
- Fewer copy-paste handoffs and fewer transcription errors.
- Every write is validated and logged.
- A clear failure path when the model or an API is unavailable.
- Integration code and documentation your team can maintain.
Deliverables
- An integration design with systems, data flow and permissions.
- API or webhook endpoints with authentication.
- Input and output schemas, including validation and rejection rules.
- Retries, timeouts and an idempotency strategy for writes.
- Structured logs and error alerts.
- Tests for the failure paths, not only the happy path.
- A runbook and a handover session.
- A security note covering what leaves the environment and what is stored.
Evidence
A private agent platform with tools on NVIDIA DGX Spark
Deployed an agent platform on customer-owned hardware and extended it with tools and agent capabilities.
Read the case studyAn agentic workflow that deploys a repository to local, Docker or Azure
Built a platform that connects a repository to local, Docker and Azure deployment targets.
Read the case studyFit and boundaries
This is a good fit when
- At least one system with an API, webhook or reliable export.
- A clear write-back target and an owner for the data.
- An AI step that already has a defined input and output.
- A team that wants the AI inside its existing tools.
This is not a fit when
- No API or export path. Some systems need a different project before an AI step makes sense.
- A full web application build. That is outside this practice.
- Unrestricted write access with no approval or audit path.
- A one-off manual task that is cheaper to keep manual.
How it works
- 01
Map the systems
What has an API, what has an export, and what has neither. The integration shape follows the systems, not the other way round.
- 02
Define the contract
The exact input, the exact output, what is allowed to change, and what happens when the model returns something invalid.
- 03
Build and test the failures
Authentication, retries, timeouts and the rejection path. A demo that only works when everything succeeds is not an integration.
- 04
Hand over the operations
Logs, alerts, a runbook and a session with the team. The integration should be understandable without the person who wrote it.
Pricing and timing
Fixed-price engagement
€3,000 to €7,000 2 to 4 weeks · EUR, VAT not applicable at present
Fixed price for one integration path, two to four weeks. Larger multi-system builds are quoted separately.
- Written scope and acceptance criteria before work starts.
- 40 to 50 percent deposit reserves the calendar slot.
- Milestone invoices and 14-day payment terms.
- A checkpoint where either side can stop with paid work settled.
Questions
Which tools can you integrate with?
Anything with a documented API, webhook or reliable structured export: CRM, helpdesk, ERP, spreadsheets, email, internal services. If a tool has no integration path, I will say so before the build.
Do we need an API key for the model?
Yes, or a private model endpoint. The key is stored in your environment, not in the code. The integration is designed so the model can be swapped without rewriting the workflow.
How do you handle security?
Least-privilege credentials, validation before writes, an audit log and a clear data-flow note. If the data is regulated, the integration can run inside your environment or a private cloud.
No-code or custom integration?
Use a no-code tool when it fits. If the workflow needs validation, retries, permissions or a model with a defined output schema, custom code is usually more reliable and easier to debug.
Page last updated: October 2026