1. Map the process as it actually operates
Automation fails when a documented happy path is mistaken for the whole process. Observe where information enters, who decides, which systems change, how exceptions are resolved, what evidence is required, and which delays are caused by policy rather than technology.
This map reveals whether the opportunity is task automation, system integration, workflow orchestration, decision support, or a product redesign. It also prevents a team from automating waste that should have been removed first.
2. Buy when the process is common and configuration is enough
Packaged workflow tools are strong when the process is well understood, integrations are supported, permissions fit, and the operating team can own configuration. They provide speed, established administration, and lower initial engineering responsibility.
Evaluate beyond the demonstration. Important questions include data ownership, audit history, environment separation, error handling, vendor limits, pricing as volume grows, and what happens when a connector or workflow changes.
3. Integrate when the value is trapped between systems
Sometimes the workflow already exists inside capable platforms, but people bridge them manually. API integration, events, queues, and controlled synchronization may remove the friction without creating another application or replacing systems that still fit.
Integration design must include record ownership, identifiers, retries, duplicate handling, reconciliation, monitoring, and a route for human correction. A successful API response is not the same as a completed business process.
4. Build when the workflow is differentiated or control is essential
Custom orchestration is justified when the process creates business advantage, crosses unusual systems, requires a tailored operating interface, or carries controls that packaged tools cannot express cleanly. The organization gains fit and ownership while accepting responsibility for a maintained software product.
A custom system does not mean every component must be built. Identity, messaging, storage, model access, and common integrations can still use managed services. The custom layer should concentrate on the workflow and decisions that are actually distinctive.
5. Add AI only at the variable boundary
Use deterministic rules for known calculations, policy, sequencing, permissions, and irreversible actions. Add AI for bounded language or perception tasks such as classification, extraction, summarization, and recommendation. Use an agent only when adaptive planning across approved tools materially improves completion.
The strongest automation architecture may combine all three: a deterministic workflow controls state, integrations move dependable data, an AI capability handles variable information, and a person remains responsible for consequential decisions. The right answer is the least complex system that can operate the real process safely.
- Rules for known policy and sequence
- Integrations for dependable system movement
- Models for variable language or perception
- Agents for adaptive multi-step tool use
- People for accountable consequential decisions