Skip to main content
Scope is the agreed description of what an engagement covers and what it does not. Everything in a consulting engagement follows from scope: what the design phase produces, what gets built, and what handoff looks like. Getting scope right — before design or build work begins — is one of the most consequential parts of the process.
Scope determination happens during the Discovery phase. This page explains what the scoping process examines and why each factor matters. It does not publish timelines or prices; those are determined individually per engagement. See Scope & Boundaries for the broader context of what is documented freely versus what requires a consulting engagement.

​
Why scope is determined before anything else

When the boundaries of an agent are unclear going into design, two things go wrong: the team doing the work makes assumptions that turn out to be wrong, and the organisation running the agent later asks it to do things it was never designed to handle. Both outcomes reduce trust in the system and create rework. A clearly defined scope means both sides know what success looks like at each phase, what is explicitly out of scope, and what would constitute a change to the agreed engagement.

​
What the scoping process examines

Scope is not a single number or a package selection. It is an assessment across several dimensions, each of which affects the shape of the engagement.
The blueprint is organised around departments — each with its own agents, SOPs, and defined interfaces. The first scoping question is which departments are in scope for this engagement. A single-department engagement has a fundamentally different shape from one that involves coordinated agents across several functions.Each additional department brings its own processes, its own people who need to be interviewed during Discovery, and its own set of system connections. Scope grows with department count.
Within each department, workflows vary in complexity. A linear workflow — trigger leads to action leads to outcome — is straightforward to specify and build. A workflow with multiple conditional branches, exception paths, or decision points that depend on external data is more complex.Complexity is assessed during Discovery by mapping the workflow in detail: what starts it, what decisions are made, what actions are taken, and where it can fail or escalate. Undocumented exceptions are one of the most common sources of scope expansion discovered late.
The blueprint uses an adapter pattern: the agent operates against a stable internal interface, and adapters connect that interface to the real external systems in your environment. The number, age, and documentation quality of those external systems directly affects how much integration work the engagement involves.Modern systems with well-documented APIs require less integration effort than legacy systems, internally developed platforms, or systems with limited or undocumented interfaces. This is assessed during Discovery — not assumed in advance.
Building an agent against a workflow that is already clearly documented — written SOPs, defined inputs and outputs, known exception cases — is faster than building one against a workflow that exists primarily as institutional knowledge. If the process is not yet documented, part of the engagement may include surfacing and formalising it before agent design can begin.This is not a barrier to engagement; it is a factor that affects scope. Many organisations find that the Discovery phase produces useful process documentation as a side effect of the work, regardless of whether the engagement proceeds.
High-volume agents have different infrastructure and reliability requirements from low-volume ones. An agent handling a small number of carefully reviewed actions per day has a different operating profile from one processing a large number of automated interactions continuously. Volume expectations are captured during Discovery and affect architectural decisions made in the design phase.

​
The principle of starting narrow

The most consistently successful scoping approach is to begin with a single, clearly bounded workflow in one department and expand from there once that first agent is validated in production. Starting narrow does not mean the ambition is limited — it means the first engagement produces something that is fully working and trusted, rather than something broad and partially working. Subsequent engagements can build on that foundation, and agents can be designed from the outset with later expansion in mind.
If there are multiple workflows or departments you want to address, capture them all during Discovery. The scoping output can include a prioritised view of what to tackle first and how later engagements would relate to it — without committing to build everything at once.

​
Scope changes during an engagement

The scope agreed before build begins is the reference point for the engagement. If something changes after the design is approved — a new integration requirement, a workflow branch that was not captured, a change to an existing system — that is a scope change, and it is handled formally. Changes are not absorbed silently or refused categorically. They are assessed for their effect on the engagement, discussed openly, and agreed before any additional work proceeds. Small adjustments are often accommodated; structural changes are scoped as separate work. The best way to avoid mid-engagement scope changes is thorough Discovery. The more completely workflows and systems are understood at the start, the less often surprises appear during build.

​
How scope connects to a proposal

Once Discovery is complete and scope is defined, an individually tailored proposal is produced. The proposal reflects what was actually found during Discovery — not a standard package applied generically. There is no published pricing on this site because scope varies enough between organisations that a meaningful figure cannot be given without first understanding the specific situation.

Engagement model

How an engagement proceeds from discovery conversation through scoping, design, implementation, and handoff.

Scope & Boundaries

The precise line between what this documentation covers freely and what requires a consulting engagement.