Direct answer
Useful engagements end with something buildable rather than a strategy deck: one workflow chosen against evidence, an honest readiness assessment of the systems behind it, the governance model that will apply, and a scoped first build with acceptance criteria. The output should be specific enough that a different team could execute it.
Agentic AI consulting
Advisory work that identifies which workflows are suitable for agentic automation, assesses whether the surrounding systems can support it, and defines the governance and sequence for building it.
What the engagement should produce
Each of these is a document someone can act on rather than a slide.
A chosen workflow
One candidate, selected against readiness criteria, with the rejected alternatives and reasons recorded.
A readiness assessment
Whether operations can be named, permissions enforced, writes retried safely and changes recorded.
A governance model
Risk tiers, who approves what, and the shape of the audit record.
A scoped build
The first named operation, its acceptance criteria, and the evidence that will prove it worked.
A stop condition
What result would mean this workflow is the wrong candidate, agreed in advance.
The readiness assessment is the part that gets skipped
Most disappointment traces to a workflow chosen for business value without checking whether the systems behind it can be governed. If a business action cannot be named as a single call, or permissions are decided by the caller, the agentic work is blocked on integration regardless of how attractive the use case is.
Advice that survives contact with the estate
Recommendations that come from reading the actual systems — the schemas, the interfaces, the permission model — hold up. Recommendations from workshops alone tend to describe a company's intentions rather than its software, and the gap surfaces during the build when it is most expensive.
The Propose–Decide–Execute pattern
CodeDTX builds agentic systems on the Propose–Decide–Execute pattern: agents may only write proposals with evidence attached, a named human records an approval or rejection with a reason, and a separate execution layer carries out approved work and logs the artifact. No agent holds a write tool to the outside world.
- 01
Propose
The agent analyses live system state and drafts a change, with the evidence it relied on attached to the proposal.
- 02
Decide
A named human approves, edits, or rejects with a reason. Risk tier determines who is allowed to decide.
- 03
Execute
A separate execution layer performs approved work — merge, publish, call, write — and records the resulting artifact.
- 04
Audit
Actor, reason, evidence, artifact, tokens, and cost are retained for every run, so any decision can be reconstructed later.
The six layers we build and review against
- 1
Agent layer
Agent architecture, tool use, memory and context, multi-agent patterns, structured outputs, orchestration.
- 2
Integration layer
MCP servers, tool contracts, API and database adapters, authentication, permissions, legacy system access.
- 3
Knowledge layer
Retrieval and RAG, vector and search architecture, enterprise knowledge sources, data access controls.
- 4
Reliability layer
Evals, tracing, observability, cost and latency budgets, fallbacks, regression tests.
- 5
Safety layer
Guardrails, prompt-injection defense, PII and data boundaries, human-in-the-loop gates, audit trails.
- 6
Product layer
The application people actually use: interfaces, approval queues, and operational runbooks.
Frequently asked
How is this different from a general AI strategy engagement?
Scope and output. A strategy engagement surveys opportunities across the organisation; this picks one workflow, assesses the systems behind it, and produces a build plan with acceptance criteria. It is narrower on purpose, because the narrow version is the one that gets built.
Can consulting and the build be separated?
They can, and the assessment should be written so another team could execute it. In practice the readiness findings usually reshape the build scope, so keeping a short feedback path between the two avoids re-deciding things.
What if the assessment says no workflow is ready?
That is a useful outcome delivered cheaply, and it names the specific integration work that would change the answer. It is considerably better than discovering the same thing partway through a build.
Have a workflow that should become AI-enabled?
Tell us about the system it lives in. We reply from an engineering seat, not a sales deck.