--case-agentic-design-opsAgentic system · Design Ops · 2026 – now

Agentic Product Framework.

Every challenge passes the gates.

A product framework and a team of agents I designed from scratch, built on Amplified Intelligence (AI). Squads decide what to build before building it, and every squad in its domain runs on it.

Leaner projects, shared knowledge
Metrics that move the needle
Continuous improvement
Next: every online squad

Role: Founding Designer · creator of the framework and CASTLE
Team: My current squad at MANGO (SCALE, Experimentation & Growth)
Timeline: 2026 – now
Status: Live testing

Fig. 1 · Agentic system · Design Ops

My role

Founding designer: I created and implemented the framework, and designed and implemented CASTLE.

Built inside SCALE, MANGO Online's Experimentation & Growth domain, for the product squads that decide what to build next.

01
Deep discovery of what digital product teams really need, before designing anything.
02
The phases, gates and guardrails: the sequence no squad can skip.
03
Orchestration: the agents and skills that add real value to the framework, and nothing more.
04
Rollout and live testing in GitHub repositories, on real work.

My role, block by block

TeamDesigned and implemented by me, validated and reviewed together with the PO Lead, who owns the product side. The squads bring the challenges; the framework makes sure decisions pass the gates first.

Context

I started in one of SCALE's squads, working for the visual merchandising users: the people who run product promotion and visibility on the web, from product pages and listings to menus and regionalization.

Then Amplified Intelligence arrived, and with it the chance to create cross-cutting opportunities for SCALE's two squads. So we formed a third one: to improve processes, speed up low-uncertainty projects with AI, research how to solve the high-uncertainty ones, and make teams more efficient.

As founding designer I also mentor and follow up the designers of SCALE's two squads, running design critiques, co-creation sessions and AI workshops.

Problem

Three gaps kept showing up:

The real problem
A mindset of continuous featuring. New features kept coming without stepping back to ask whether the system and the current workflows actually worked.
Speed
Delivery and implementation slowed by legacy technology: data that wasn't connected or integrated with the tools teams use today.
Measurement
How do you measure internal tools? Nobody had a good answer. So we defined one.

The system

Three phases, every one with its gates.

A challenge only moves forward when it passes the gate in front of it.

Now ridingDISCOVERFrom challenge to experiment.

■ Discover□ Create□ Measure

Discover · Live

G0Is the challenge worth it?

G1Problem and metrics before solutions

G2A hypothesis worth testing

G3The success signal, set before any data

→ An experiment ready to build

Create · Live testing

Handoff to dev, or vibe coding

Measurement built in from day one

G4Ready to go live?

→ A solution in production

Measure · After Create

Read the signals

G5Persevere, pivot or stop, with evidence

Learnings feed the next Discover

→ A decision, and a learning

These are the headlines. The details, in an interview or working together.Let's talk ↓

Key decisions

01
Discovery before any agent.
Before designing a single agent, a deep discovery of what product teams actually needed and where their time went. The framework answers those needs, not the other way round.
02
Gates and guardrails before agents.
An agent adds nothing just by being there. It adds value when it has a gate to enforce, so the gates were designed first and the agents came after, only the ones that add value.
trade-off: Less to show at first: gates are rules, not features.
03
CASTLE instead of adapting HEART.
HEART was built for consumer products, where users choose. In internal tools they don't, so adoption and retention lose meaning. Measuring an internal tool with consumer metrics gives the wrong answers with confidence. CASTLE measures what does change: cognitive load, efficiency, errors.
trade-off: A framework nobody knew yet, so it had to be explained before it could be used.
04
Test live, one phase at a time.
Each phase is tested live in real GitHub repositories, on real work, before the next one ships. Teams adopt it without stopping what they're doing.
trade-off: The system is incomplete by design, and we say so.