Why connections matter
Organizations often have the systems they need already: a CRM, a finance platform, a project tool, a document library. What’s missing is the connections. Information is copied by hand, the same customer exists in three places with three slightly different addresses, and asking how a project is tracking against its budget means opening four tools.
APIs: software talking to software
An API, or application programming interface, lets one piece of software ask another for information or tell it to do something. Modern platforms generally offer them. If a system has an API, we can connect it.
Common API connections:
- Syncing records. Customers, contacts, products or projects kept consistent across systems.
- Triggering actions. A new order creates a project, a signed form updates a record, a published event appears on the website.
- Pulling in data. Schedules, prices, availability or metrics brought into a site or dashboard.
- Pushing out updates. Leads to a CRM, submissions to a database, notifications to a team channel.
Good integrations handle the unglamorous details: retries when a system is slow, clear logs when something fails, protection against duplicate records, and caching so one slow service doesn’t slow everything else.
MCP: connecting AI tools
MCP, the Model Context Protocol, is an open standard for connecting AI tools to other systems. A system exposes its capabilities once through an MCP server, and any compatible AI tool can use them.
With MCP in place, an assistant like Claude can:
- Look up an order, a customer or a policy.
- Pull this month’s numbers into a report.
- Create or update a task in a project tool.
- Search a document library and cite what it finds.
- Draft a response from several systems at once.
Without connections, an AI tool knows only what someone pastes into it.
Deciding what AI can touch
We design each connection around three questions:
- What can it read? Only the information the task needs. Sensitive data is excluded or restricted.
- What can it change? Reading and writing are separate permissions, and many connections should be read-only.
- What needs a person to approve? Sending messages, changing financial records, deleting data or publishing content usually go through a person first.
We also decide whose permissions an AI tool acts with, how its actions are logged, and how access is revoked. An assistant should never be able to do more than the person using it.
Integration patterns
- Direct integrations between two systems for a specific, stable flow.
- Middleware or automation platforms when many systems exchange information and non-developers need to adjust the flows.
- Custom services when the logic is specific to the organization or existing tools can’t handle it.
- MCP servers when AI tools need a system’s information or actions, with tight permissions.
- Event-driven flows, where one system announces a change and others respond, keeping systems loosely coupled.
We choose the simplest pattern that reliably does the job and that the organization can maintain.
Planning for change
Vendors update their APIs, organizations switch platforms, new tools arrive. We design connections so a change in one system doesn’t mean rebuilding the rest: each system does one job, and the connections between them are clear and documented.
How we build connections
- Map how information moves today, and where it’s re-typed or stuck.
- Connect first where it saves the most time or prevents the most errors.
- Test, monitor and document each connection, and keep supporting it as the systems around it change.
