What systems architecture covers
Once AI is part of the work, the harder question is how everything fits together:
- Systems of record: where each kind of information officially lives, from customers in the CRM to documents in the drive.
- Data flows: what moves between systems, how often, and what triggers it.
- Integrations: the APIs, connectors and protocols that link systems, including MCP for AI tools.
- AI placement: where AI reads, drafts, decides or acts, and with what information.
- Permissions: who and what, AI agents included, can see and change each kind of data.
- Human checkpoints: where a person reviews, approves or can step in.
- Failure handling: what happens when a system is slow, down or does something unexpected.
- Observability: how the team knows it’s working, and how problems are traced.
Why architecture matters more with AI
AI-assisted building does what it’s shown, quickly. A clear architecture gets followed. A vague one gets filled with assumptions, which surface later as data in the wrong place, duplicated records, or agents with too much access.
AI also multiplies the consequences of structure. In a well-connected organization, an assistant can safely look up an order or pull a report. In a poorly connected one, AI can’t help, or works from stale copies.
Principles we design by
- Buy the core, build the connections. Organizations often already have the systems they need. Keep them, and build the thin layer that connects them and fits them to the work.
- One source of truth for each thing. Copies drift, and drift erodes trust.
- Composable over monolithic. Parts that each do one job can be replaced without rebuilding everything. All-in-one platforms tend to become the thing you’re working around in year three.
- Least privilege. Agents and integrations get only the access they need, with reading and changing as separate permissions.
- People where it matters. Sending, paying, deleting and publishing have a human checkpoint until the system has earned trust.
- Design for failure, so one slow or unavailable system doesn’t bring down the rest.
- Keep it understandable. Simple, documented systems are easier to secure, run and fix.
Choosing technology
We pick technology for how quickly it gets something real in front of people, how easily it connects, and how little it traps you later: usually modern, well-supported platforms with good APIs, data you can move, and strong support from AI tools, because a platform that connects poorly taxes every later change. When an organization already runs a platform well, we build around it.
Security, privacy and governance
Architecture is where security and privacy are decided: where data is processed and stored, what leaves the organization, which AI providers are used and how, and what’s logged and for how long. Compliance and data residency rules shape it from the start.
Someone needs to own each integration and agent, know what it does, and be able to switch it off. We document the architecture in plain language, for the people responsible for it as well as the developers.
From current state to build
Systems architecture follows workflow discovery and opportunity mapping:
- Map the current state: the systems and how information actually moves.
- Design the target for the opportunities chosen, as simple as the work allows.
- Review it with the people who run the systems, as a diagram and a short written explanation, and refine it.
- Build one flow at a time, verifying each before adding the next, with a named owner for each.