It is built in stages with verifiable deliverables: a diagnostic of the process and your systems, the connectors, the process core with its governance, a parallel run against what you do today, and only then go-live, with the code in your repository. Each stage ends with evidence, not a slide deck.
Step 1: what happens in the diagnostic?
One process is chosen and truly understood. With the people who run it, we walk through how it works today: which systems it touches, where it gets stuck, which exceptions appear and who decides them. Each system and its entry point get identified, and the starting point is measured so there is something to compare against at the end.
The result is an honest decision: whether an agentic system, a classic integration or nothing yet is the right answer. Also a bounded scope: the first process, not the whole company.
Step 2: how is the systems and risk map made?
For each system: which data is the source of truth, which entry point is used (see connectors), what permissions are needed and who authorizes them. For each action in the process: what risk it carries and whether it requires human approval. This is also where we decide which data may reach a model and which may not (see security and data).
Step 3: what gets built first?
The connectors, starting with read access. With them, tested against a non-production environment, you confirm the agent sees what it should and nothing more. Each write action is added one at a time, with its limit and its test. It is the least glamorous part and the one that most determines whether the system can be trusted.
Step 4: how is the core assembled?
The process is written down: its steps, rules, exceptions and the points where a person decides (see agentic cores). The agents are instructed, their limits are defined in code, and the audit log, the stop switch and the view where the team supervises are built (see governance). Models are chosen per task: one for classifying, another for drafting or reasoning through a hard case. We build on several providers, Claude among them.
Step 5: how is it tested?
With anonymized real cases and with cases designed to break it: ambiguous documents, contradictory data, attempts to get around a limit, a system that doesn't respond. The test that matters is the one that tries to violate the rule and confirms the system stops it. It is also run through the channel where the work actually arrives, not only by calling the code directly.
Exit criteria are agreed before starting: what must happen, at what quality and with how much human intervention, for the agent to count as ready.
Step 6: what is a parallel run?
The agent works alongside the current process. Its proposals are compared with what people do, differences are reviewed, and adjustments are made. When results are consistent, real work is transferred gradually, starting with the lowest-risk cases. Meanwhile, today's process stays alive as a fallback.
Step 7: how does handover work, and what comes after?
The system is left running, with its documentation, its audit log and people on your team trained to supervise it. The code lives in your repository and your infrastructure. If you decide to continue without us, you can. If you decide to keep going together, the next work is based on evidence: which cases escalate most, where a different limit makes sense, which process comes next.
To go back to the underlying questions, read the FAQ. For the full range, see the guide. If you already have a process in mind, the first step is a conversation: hello@innova.black.