Connecting the systems that do not talk today
The ERP does not know what happens in the store, the CRM cannot see billing, and someone on the team acts as a bridge copying data by hand. That can be connected.
Key takeaways
- Connecting two systems on the happy path is days of work; what decides whether the integration survives is what happens when the other system is down or the same event arrives twice.
- That is why Quarl builds with idempotency, retries with backoff, a dead-letter queue for what could not be processed, and monitoring with alerts.
- An integration that fails silently is worse than none, because the business keeps operating on incomplete data without knowing it.
- Model Context Protocol servers expose systems as standardized tools, so any AI agent consumes them without brittle bespoke integrations.
Operating track record
Three years operating the system in production — not one delivery and an exit.
The most frequent failure in RAG architectures, solved with structured metadata at ingestion.
The proposal arrives within 48 hours with fixed scope, price and date. If scope changes, it is quoted separately and approved first.
The bridges we get asked for most
- Online store with inventory and billing. So an order draws down stock, generates the invoice and notifies, without anyone touching anything.
- CRM with billing and collections. So sales sees the real account status without asking accounting for a report.
- Legacy systems with new applications. When the old system works but exposes nothing, and replacing it is not an option.
- Forms and channels with the database. So what arrives via web, WhatsApp or email lands structured where it needs to be.
- Your own APIs for third parties. When your customers or partners need to consume your information in a controlled, documented way.
- MCP servers. Exposing your systems as standardized tools so any AI agent can use them without brittle, bespoke integrations.
Integrating is easy; staying integrated is not
Connecting two systems on the happy path is days of work. What decides whether the integration survives is everything else: what happens when the other system is down, when it returns data in an unexpected format, when the same event arrives twice, when a full day has to be reprocessed without duplicating records.
That is why everything we build carries idempotency, retries with backoff, a dead-letter queue for what cannot be processed, and monitoring with alerts. An integration that fails silently is worse than none, because the business keeps operating on incomplete data without knowing it.
Ranges and timelines
| Scope | Example | |
|---|---|---|
| Single integration | Two systems, one data flow, with monitoring and retries. | 2–3 weeks |
| Multiple integrations | Three or four systems synchronized with business rules between them. | 4–6 weeks |
| Your own API | Documented interface for third parties, with authentication, rate limits and versioning. | 4–8 weeks |
| MCP server | Your systems exposed as tools for AI agents. | 2–4 weeks |
What we integrate with
Related services
AI automation
Applied where there is volume and stable rules, not where there is expectation.
View serviceSoftware development
The system around the model, not just the model.
View serviceAI agents
LangGraph orchestration, durable state and human approval on steps with consequences.
View serviceMobile applications
iOS and Android, with inference on the correct side.
View serviceFrequently asked questions
What if our system has no API?
There are ways out and they depend on the case: scheduled file exchange, direct database reads when the vendor allows it, or an intermediate layer exposing what the old system does not. What we do not recommend is automating the graphical interface: it works until the vendor changes a screen and everything breaks without warning. If your system is completely closed, we tell you on the first call.
What happens if the other system goes down?
The integration assumes it from the design: retries with backoff, a queue for what could not be processed, and an alert when something has been pending too long. When the system returns, the backlog is processed without duplicating records. That behavior is what separates a production integration from a script that worked once.
What is idempotency and why do you mention it so much?
It means processing the same event twice produces the same result as processing it once. It matters because in distributed systems events do get duplicated: a retry, a webhook delivered twice, a reconnection. Without idempotency that means double invoices or inventory drawn down twice. It is one of those things that never shows up in the demo and always shows up in production.
What is an MCP server?
Model Context Protocol is a standard for exposing systems and data as tools a language model can use. Instead of writing a bespoke integration for every agent you build, you expose your systems once and any agent consumes them. If you are planning several agents, starting here saves a lot of repeated work.
What does maintaining an integration cost?
Infrastructure is usually low: roughly USD 20 to 80 monthly for typical volumes. The real cost appears when the system on the other side changes its API, and that happens. That is why we document external dependencies and leave monitoring configured, so the change gets detected the same day rather than three weeks later.
Can you document our existing API?
Yes, and it is a more frequent request than you would think. OpenAPI documentation generated from the code, with examples and a sandbox, plus versioning if needed. When third parties consume the API, this dramatically reduces support load.
Do you work with region-specific systems?
Yes: electronic invoicing, local payment gateways, shipping platforms and regional ERPs. When a system we do not know shows up, the first thing we check is what it exposes and how stable its interface is, and we assess that before quoting so we are not promising on assumptions.
Book 15 minutes
Tell us what you are building, or what stopped working. You leave the call with a concrete answer: it can be fixed, it can be built, or it isn't worth it.