Alfonso Graziano
Based in Italy · 2026
Workshop canvas

AI-native team canvas.

A workshop template for designing how your team adopts AI-native engineering: an operating model, not a tool checklist.

?How to use this canvas

Export this page to PDF or take a screenshot, then load it into Miro. If you prefer, just print it. Anything your team can write on works.

Run a short workshop with your team, around 60 to 90 minutes. Go box by box and answer the prompts together, using sticky notes for what is already in place and what is still missing.

Come back to the canvas every two or three months. As you gain experience, your practices and tools will keep changing, so the canvas should change with them.

Step 01Frame the work

Get clear on your team, your system, and why you are going AI-native, before you change how you work.

01Team context

The team, system, and constraints that shape how AI fits.

What product or system does the team own?
Greenfield, brownfield, or mixed?
Where are churn and blast radius highest?
What team is filling this canvas?
What are the main technical domains?
What constraints shape the work: compliance, client rules, security, uptime, budget, deadlines?
02Adoption north star

Why we're going AI-native, and what better looks like.

What outcome are we optimising for?
Which current bottleneck are we removing?
What would make this adoption a failure?
Speed, quality, learning, cost, predictability, or developer experience?
What should be visibly better in 30, 60, 90 days?
What must not get worse while we adopt AI?
03AI-native use cases

Where agents help today, and where they don't yet.

Which tasks are well-scoped and easy to verify?
Which need human judgement before any code?
What stays fully human for now?
Which tasks are repetitive and low-risk?
Which are not safe to delegate yet?
Which should use AI only for drafting, review, or analysis?
Step 02Design the system

Decide how humans and agents share the work: who owns what, what context agents need, and how you write intent.

04Human roles and accountability

Who owns intent, review, and production outcomes.

Who approves the spec or plan before work starts?
Who decides a change is safe to ship?
Which decisions must never be delegated?
What workflows can be fully automated?
Who owns the problem definition?
Who reviews AI-generated code?
Who owns incidents caused by AI-assisted work?
When should the agent stop and ask for help?
05Context inventory

What agents need to know, and where it lives.

What context is needed to work safely?
What is stale, missing, or tribal knowledge?
What should not be loaded because it creates noise?
What skills will the team need to work this way?
Where does that context live today?
Which context is reliable and current?
What rules, style guides, or architecture notes should be reusable?
What examples should agents copy?
06Specification system

How we write intent before implementation.

Which work needs a written spec first?
What must every spec include?
Where do specs live, and when do they go stale?
What is the minimum spec format?
Goal, context, constraints, acceptance criteria, non-goals?
Who reviews specs, and how short should they be?
Step 03Prove it's safe

Agree the tools, checks, and boundaries that make AI-assisted work safe to ship.

07Tool and integration stack

The agents, MCP servers, CLIs, and skills we trust.

Which tools are approved for code, data, and client work?
MCP server, or CLI script / skill instead?
How do we avoid too many tools and context pollution?
Which AI tools will the team use?
What credentials or permissions do tools need?
How easy is it to switch tools later?
08Verification and quality gates

How we prove AI-assisted work is correct.

What deterministic checks must pass before merge?
When should an LLM reviewer be used, and for what?
What if code passes tests but feels wrong?
Which tests are required for AI-generated changes?
What security, dependency, contract, or accessibility gates are needed?
Which checks block merge, and which only warn?
09Delivery and runtime safety

Getting changes into production safely.

What needs feature flags, canary, or staged rollout?
What telemetry must exist before release?
What is the rollback process?
Which stateful changes need special plans?
What alerts or SLOs show that a change is unsafe?
How do production incidents feed back into specs and tests?
10Security, privacy, and governance

The boundaries that keep tools safe.

What data can and can't be shared with AI tools?
What permissions should each tool have?
What approval is required before destructive actions?
Which tools are approved, and who approves new ones?
How are secrets protected?
How will we audit tool use?
Step 04Improve and scale

Measure whether it is working, and build a loop that keeps the system learning after every change.

11Metrics and economics

How we know it's working: outcomes, not demos.

How do we measure cycle time and change-failure rate?
How do we track AI cost and latency?
What metric would tell us to slow down?
What baseline metrics do we have today?
How do we measure developer experience?
How do we measure rework from unclear specs or bad context?
12Learning loop and memory

How the system improves after every change.

What do we update after each change ships?
How do incidents become regression tests?
How do we stop context and docs from rotting?
Where do we store lessons learned?
When do we update rules, specs, prompts, or skills?
How do new team members learn the workflow?
Based on “Learning AI-Native Software Engineering”