Assess. Architect. Build. Align. Amplify.

Most consulting engagements end with a document. A strategy deck, a recommendations report, a roadmap that lives in a Google Drive folder and gets referenced once. The client paid for analysis. They received analysis. The operation didn't change. The bill was real, but the value was theoretical.

This is the standard model. It is also the reason the consulting market has a credibility problem. Clients have learned, correctly, to be skeptical of strategy work that isn't attached to execution. And the execution market is its own problem: firms that execute without diagnosing first, that build before they understand what's broken, that deploy AI because the client asked for AI rather than because AI is what the problem requires.

The Krastor Method exists because both failure modes (strategy without execution, execution without diagnosis) are predictable and preventable. The method is a structured sequence that transforms an initial diagnostic conversation into a running, observable, improving production system. It is applied flexibly (not every engagement runs all five stages in strict order), but it never permits jumping to solutions before understanding the problem, and it never produces a deliverable that exists only on paper.

Why method matters in a market full of "we'll figure it out"

The AI consulting market is documented and segmented. The 2026 Bushe.co and Onpattison analysis describes a four-tier structure: Tier 1 is the global management consultancies with AI practices and enterprise relationships. Tier 2 is the specialized AI strategy firms targeting large enterprise budgets. Tier 3 is the technical implementation shops (machine learning engineers, data scientists, model fine-tuners) who build things but don't diagnose. Tier 4 is the SMB and mid-market segment: businesses that need shipped production systems, not strategy decks, but who don't have the budget or operational complexity that the Tier 1 and 2 firms require.

The market is over $30 billion and growing at more than 20% per year. The Tier 4 segment (the businesses Krastor serves) is the most underserved. Tier 1 and 2 firms don't quote them. Tier 3 shops don't diagnose them. They get sold either a strategy deck they can't execute or an implementation that starts without sufficient understanding of what needs to be built.

In this market, the difference between a Tier 4 firm that builds durable client relationships and one that churns through projects is a repeatable method. Method is what allows a small team to operate at consistent quality across diverse engagements. It is what allows a client to understand what they're buying: not just the deliverables of a single phase, but the operating logic of the whole engagement. And it is what prevents the two most common failure modes: strategy that doesn't ship, and builds that don't solve the right problem.

Assess: the work that happens before any architecture decision

Every Krastor engagement begins with Assess. Not a sales call. Not a requirements gathering session. A structured diagnostic that produces a written deliverable (a stack assessment) that the client keeps regardless of what happens next.

The Assess stage maps the operation across four dimensions: how the business runs day-to-day (operations); how it generates and converts revenue (pipeline); what technology it runs on (stack); and how much of that technology is covered by AI or automation (AI coverage). The output is a named dollar figure for the cost of inaction in each dimension: the quantified cost of leaving each identified problem on the table for another year.

This is not a theoretical exercise. "You have a manual process that takes 12 hours per week, valued at $65 per hour, running 50 weeks per year: that's $39,000 per year in labor cost, plus the errors introduced by manual data entry, plus the delay in customer response time while the process runs." That is not a PowerPoint slide. That is a business case for a specific automation, costed against the actual operation. The diagnostic produces this for every identified gap.

"Every Assess produces a document the client can act on whether they hire us or not. The engagement starts with honesty, not sales."

The Assess deliverable also includes a prioritized sequence: which problems are worth solving first, in what order, and why. Sequencing is an architectural decision: some fixes are prerequisites for others, some create infrastructure that subsequent phases use, some have ROI that dwarfs the cost and should be done first regardless of complexity. The Assess stage surfaces this sequence before any build decision is made.

No architecture decisions are made before Assess is complete. This is a hard rule. It exists because the single most common failure mode in AI consulting is the project that starts with a solution ("we need an AI chatbot," "we need to automate our invoicing," "we need a data dashboard") and works backward to justify the solution rather than forward from the problem. Assess prevents this by establishing the problem, the cost, and the priority before any solution is designed.

Architect: design before code, every time

Once the Assess is complete and a phase is committed, the next stage is Architect. Design before code. Every time, without exception.

The Architect stage produces four outputs: an integration map showing which systems connect to which and what data flows between them; a data-flow diagram showing where information enters the system, how it's transformed, where it's stored, and how it's accessed by downstream processes; a tier roadmap defining the Foundation → Tier 1 → Tier 2 → Tier 3 sequence with milestones, prerequisites, and success criteria for each phase; and a vendor stack decision (which tools, which models, which infrastructure, and why) documented before any build begins.

The integration map is where most AI projects fail. The AI itself (the model, the prompts, the response logic) is the easy part. It is the connective tissue between the AI and the systems it needs to read from and write to that kills projects. Which CRM fields does the automation need? In what format? With what permissions? What happens when a field is null? What is the error handling when the API is down? These questions are not interesting. They are also not optional. Every integration question that isn't answered in the Architect stage becomes a production bug.

The data-flow diagram is the document that prevents the most expensive class of errors: deploying an AI system that works in isolation but fails in production because the data it needs isn't available, isn't clean, or isn't structured in a way the system can use. The diagram forces the question before build: what data does this system need, is that data available in the required format, and what do we need to do to make it available? Answer those questions in the Architect stage, and the build is a known quantity. Skip them, and the build is a discovery process: expensive, slow, and prone to scope expansion.

The vendor stack decision is not a preference statement. It is an architectural commitment with documented reasoning. The workflow orchestrator, the database, and the observability layer are each chosen for being open, portable, and client-owned. The model is Claude for complex reasoning, with fallback routing to open-weight models for high-volume structured tasks, swappable later without a rebuild. These decisions are made before the first line of code, documented in the architecture brief, and signed off before build begins.

Build: sometimes the answer isn't automation at all

The Build stage is where the architecture becomes a running system, and the answer is whatever the constraint actually requires: custom software, a tool replaced or eliminated, AI agents deployed, a new data layer, reporting redesigned, an org restructured around the systems, or workflow automation. When the fix is automation, the build draws on five proven patterns that underlie most business workflows. Whatever the fix, every build is held to a seven-layer production standard most shops ignore because clients can't see the invisible layers until something breaks.

The five patterns: Intake → Qualify → Route (a new lead, form submission, or inquiry enters, gets assessed against criteria, and routed to the right follow-up sequence or human owner). Data Change → Generate Document → Collect Signature and Payment (a record changes state, a document is generated from it, routed for signature, and a payment is collected (used for proposals, contracts, quotes, invoices)). Scheduled Scan → Analyze → Alert (a scheduled job examines a data source, applies analysis logic, and surfaces anomalies or opportunities to the right person). Inbound Message → Draft Response → Approve → Send (an inbound communication triggers an AI-drafted response, routes it for human review, and sends on approval (used for email, support tickets, review responses)). Event → Multi-Channel Fanout (a business event (a new booking, a completed project, a reached milestone) triggers coordinated communications across multiple channels simultaneously).

When the fix is automation, every workflow reduces to some combination of these five patterns, and the Build stage designs around the right one. When the fix is something else (software to build, a system to replace, a data layer to create) the same engineering rigor applies, against the same seven-layer production standard.

The seven layers: the application codebase (version-controlled, documented, deployed through a pipeline, not FTP-uploaded); persistence (the database layer, properly indexed, backed up, with access controls); security and safeguards (authentication, authorization, input validation, prompt injection prevention, output filtering for AI responses); the AI service layer (the abstraction between application logic and the raw model API, including retry logic, circuit breakers, fallback routing, and cost allocation); multi-agent orchestration (for workflows that involve multiple AI calls in sequence or parallel, the coordination layer that manages state and handles failures); the API gateway (rate limiting, authentication, logging for inbound requests); and observability (every prompt, response, cost, latency, and trace logged and searchable).

Most competing builds ship layers one, two, three, and maybe four. The visible layers. The ones that make the demo work. Layers five, six, and seven are invisible in demos and essential in production. Without the AI service layer, a downed API takes down the application. Without multi-agent orchestration, a complex workflow fails silently at step three and nobody knows why. Without observability, you're running blind: you can't see what the model is doing, can't explain a wrong output, can't catch a cost spike before the bill arrives. These are not premium features. They are the difference between a production system and a prototype that works until it doesn't.

Align: making the systems speak one language

The Align stage is where most AI projects fail, and where the consulting market has the least to say. Building the system is the part everyone talks about. Getting the organization to use the system, trust the system, and operate in a way that the system supports rather than fights against is the part that determines whether the system delivers its theoretical ROI or sits underutilized in production.

RAND's data is unambiguous: 84% of AI project failures are caused by leadership, process, and organizational issues, not technology. The system worked. The organization didn't adopt it. The team didn't understand what it was doing. The manager who wasn't consulted during procurement actively worked against it. The workflow the automation was designed to replace had informal steps nobody documented, and those informal steps were load-bearing.

Align makes CRM, reporting, agents, and team workflows speak one language. It involves: mapping the existing workflows that the automation touches and identifying the informal steps and workarounds that will break if ignored; documenting the new workflow so team members understand what the system does, why it does it, and what they're expected to do when it surfaces a decision for them; configuring the reporting layer so the business can see what the automation is producing in terms they care about (not "1,247 workflow executions" but "$18,400 in recaptured follow-up revenue from leads the system re-engaged"); and establishing the escalation paths for cases the automation can't handle, so humans know when they need to intervene and what they need to do.

This is the change management work that consulting firms charge extra for and then underfund. In the Krastor Method, it is not a phase you can skip. If the organization isn't aligned before the system goes live, the technical work is wasted. The system runs. Nobody trusts it. Nobody uses the outputs. The automation triggers. The human overrides it anyway because nobody explained why the automation's judgment should be trusted. Six months later, the client reports that the AI "didn't work," and cycles through their second consulting team.

Amplify: the architecture that gets better as models improve

The final stage is Amplify, and it is the stage that converts a completed project into a compounding investment.

Amplify is ongoing monitoring, upgrades, and evolution. It is not IT support, not a helpdesk that responds to tickets, not a maintenance contract that keeps the lights on. It is architecture stewardship: the ongoing decisions about what to upgrade, what new capability to deploy, and what to retire as the landscape evolves around it.

The compounding mechanism is real. Open-weight models improve on a roughly six-to-twelve month cycle. A system built on an architecture that can swap the model gets the improvement for free: upgrade the model connector, run the evaluation suite, deploy. A system built on a vendor-managed platform gets the improvement when the vendor chooses to ship it, at the pricing tier the vendor chooses to require. The architectural ownership created in the build stages is what enables the compounding in the Amplify stage.

The retainer covers the ongoing monitoring (observability dashboards reviewed on a defined cadence, anomalies investigated before they become problems, cost spikes caught before the invoice arrives); model updates as the underlying models improve or change; integration maintenance as the surrounding systems evolve; prompt iteration as the use cases mature and the edge cases that production reveals are addressed; and the strategic evolution roadmap: the ongoing conversation about what to build next, in what sequence, and why.

The Amplify retainer is not priced on hours. It is priced on the value of the systems under management: the cost-of-inaction for letting the architecture stagnate multiplied by the scale of the operation. As the operation grows and the architecture handles more volume, the value delivered per retainer dollar increases. This is the opposite of consulting pricing, where more value typically means a larger scope and a higher invoice. In the Amplify stage, the architecture does more work for the same fixed monthly cost. That asymmetry is what clients are actually buying.

Applied flexibly: a lens, not a checklist

The method is not a rigid five-step sequence that every engagement must follow in order. It is a lens for understanding what's needed and a constraint system that prevents the two most common failure modes.

Some engagements begin at Architect: the client has already run their own diagnostic, knows what they need to build, and needs the architecture designed correctly before any code is written. Some begin at Automate: the architecture is designed, the client needs production-grade implementation. Some engagements run Assess and Architect as one conversation and move directly to build because the problem is clear and the scope is narrow. The method allows this. What it does not allow is jumping to solutions before the problem is understood, or building without a documented architecture.

The method is also not sequential at the engagement level. Multiple stages can run concurrently in a live engagement. Amplify starts while Automate is still in progress, because monitoring the system from day one produces data that improves the build. Align starts before Automate finishes, because getting organizational buy-in during the build rather than after it is cheaper and more effective. The stages are a logical sequence of dependencies, not a project management Gantt chart.

"You're not buying consulting hours. You're buying a structured operating system."

What the method prevents, consistently and by design, is the most expensive mistake in the AI consulting market: moving fast on the wrong problem. A business that rushes to deploy AI because they feel behind is not moving fast. They are spending money at velocity. The diagnostic slows them down exactly long enough to establish that they're solving the right problem at the right layer in the right sequence. That pause (the Assess stage) is the most valuable part of the engagement. It is also the part most clients initially resist, because it doesn't look like progress. It is, in fact, the only thing that makes the progress worth having.