Agentic workflow in a real product team.

AI as part of the operating system.

The useful framing is not “we use Copilot”. It is that planning, coding, context, testing and observability each gain an AI-assisted step, and the process around them has to be tightened to match.

The governing principle is one sentence: AI should help the team move faster without losing control, quality or safety. Every practice below exists to keep one of those three.

The stack, by function.

Note what is unremarkable about that table. Most of it is a normal modern stack. The AI-specific rows are context, evaluation and tracing — and those are the ones teams skip.

Discovery through to an implementation plan.

AI is good at the first draft of a specification, user stories and acceptance criteria, and genuinely good at finding the questions nobody asked. It is not good at deciding what the product should be.

The step worth protecting is the one between spec and code: a structured implementation plan naming which files change, what the approach is, the edge cases, and how it will be verified. Skipping it is what produces confident, plausible, wrong work.

Context and memory are the real infrastructure.

Four kinds of memory are worth separating, because they have different lifetimes:

• Instruction memory — rules and preferences that apply to everything.
• Project memory — architecture and the decisions behind it.
• Code graph memory — how files and modules actually relate.
• Decision memory — why something was done, which is the one that saves the most time six months later.

Repository instruction files and MCP servers are how these get loaded. Keeping them short matters — see our guide to context engineering for why a bloated instruction file quietly taxes every request.

The implementation loop.

Inspect
   |
Plan
   |
Implement
   |
Self review
   |
Tests
   |
Human review

The loop is controlled rather than open-ended: scoped to named files, with tests as the exit condition and a human as the gate. Pull request review gains an AI first pass focused on correctness, security and data-loss risk — not style, which is what linters are for.

Testing, and the AI-specific kind.

Normal testing does not change much: unit tests, edge cases, end-to-end coverage. AI helps write them and is particularly good at the cases a tired engineer skips.

What is genuinely new is evaluating AI features themselves. If your product uses a model, you need golden datasets, prompt regression tests and hallucination checks, because a prompt change is a deployment and will silently regress behaviour that no unit test covers.

CI/CD, guardrails and governance.

Split automation into what an agent may do unsupervised and what it may not.

Write those rules down before the first incident, not after. The four on the right are the ones that turn a productivity story into an outage story.

Release and incident response.

At release, AI drafts release notes, migration documentation and QA checklists — work that is genuinely valuable and genuinely nobody’s favourite task.

In operations it is strongest at triage: summarising error bursts, clustering logs, and proposing a root cause for a human to confirm. The pattern holds throughout — AI compresses the time to a hypothesis, and a person still owns the decision.

Common questions.

Is this just using Copilot with extra steps?

No. Autocomplete speeds up typing. An agentic workflow changes what happens either side of the typing: planning, scoped context, self-verification, evaluation and guardrails. Teams that add the tool without the process get faster at producing work that needs redoing.

What should a team put in place first?

A repository instruction file and a rule about what AI may never touch. Those two cost an afternoon and prevent most of the problems. Evaluation and CI integration can follow once the basics hold.

Do we need new roles?

Not new headcount, but a named owner for AI practice — usually a tech lead. Someone has to own instruction files, guardrails and evaluation, or they decay into folklore.

How do we stop an agent doing something destructive?

By making it impossible rather than discouraged. No production secrets, no destructive commands, no deploys without approval, no migration edits without review — enforced by permissions and CI, not by an instruction in a prompt.

Does this work for a small team?

It works better for a small team, because there is less process to retrofit. A two-person team with a clear instruction file, scoped tasks and a test gate gets most of the benefit described here.

What this means for a buyer.

The mental model that holds up: spec, AI-assisted planning, context and memory, scoped implementation, tests, human review, CI/CD, staged release, observability, and a documented learning at the end. AI accelerates each stage; it does not remove the sequence. Simam Digital builds products this way and helps teams introduce it — see also auditing a development workflow.

A version of this article was first published in Tech Alchemy, the Simam Digital newsletter on LinkedIn.