How a 2-person design team scaled customer-focused outcomes across product and engineering by building a shared knowledge centre and embedding design into the agentic framework.
Agentic development arrived faster than most teams could plan for. Tools like Claude Code and GitHub Copilot collapsed the time it takes to ship code, but they also exposed a structural risk for businesses: agents could now execute faster than design could specify intent, validate readiness, or review outcomes. Without structure, “more, faster” would mean more, faster, with less customer focus, and the business would quickly start shipping capabilities that don’t meet customer needs.
This is a case study of the response. Over the last few months at JET Charge, my small team built two pieces of infrastructure: a Git-backed knowledge centre that gives humans and agents a shared, navigable source of truth; and a set of design gates inside the Agentic Framework that enforce design discipline at the points where it matters most: readiness, intent, and review. Together they turned design from a per-ticket service into a whole-org infrastructure.
I lead design at JET Charge, focused mostly on Illuminate, the platform managing EV charging operations for enterprise and government fleets across Australia. We serve a huge range of customers, including: Woolworths, Mainfreight, ACT Government, RACV Solar, and IKEA, who need to monitor and optimise hundreds of chargers across many sites. The product team is small. The design team inside it is just two people.
With AI growing fast, we made an early call to lean into agentic development rather than gatekeep it. The question became how does design stay load-bearing when code is no longer the bottleneck? If agents are about to write the next thousand PRs, then the leverage point isn’t reviewing each one — it’s shaping the context, the gates, and the principles those agents reason from.
I came back from The Outlook Design Leadership Conference in April 2026 with an even sharper conviction. We’re already pushing the boundaries with our transition to agentic development. Design is still incredibly important, maybe even more so. We need to use design thinking to make decisions and make sure what gets developed does actually move the needle on metrics that matter. This case study is about how we operationalised that.
Knowledge fragmentation made AI-first work brittle
Before any of the agentic gates, we had a more fundamental problem: agents had nowhere good to read from. Product context lived in Confluence pages, Figma files, customer-call recordings, and the heads of the people who’d been at JET Charge longest. Humans muddled through. Agents, which need retrievable, structured, current context, couldn’t.
So we built Beacon, a Git repository of markdown that holds the team’s collective knowledge — PRDs, customer accounts, strategy docs, the design system, engineering standards, OCPP references — in a structure agents can navigate. Every folder has a lean CLAUDE.md index file. The root index points to subfolder indexes, which point to files. Agents read maps before they read content, which keeps the context window cheap and the retrieval precise.
The discipline that made this work wasn’t technical, it was editorial. Specificity made retrieval accurate and lean indexes leave room for the model to actually think.
Customer focus had no agentic surface
Knowledge structure on its own doesn’t guarantee customer focus. The risk in any AI-accelerated team is that agents draft PRDs and design specs that sound plausible but cite no one, instead using generic personas and made-up pain points. For a platform whose value lives in deep relationships with operators like Woolworths and IKEA, that would be a disaster.
So we made customer evidence first-class inside Beacon. Every key account has its own folder populated with discovery call summaries, depot-level notes, energy-opportunity briefs, and verbatim quotes. Personas live alongside them, referencing the specific people that use Illuminate. We created a customer-call-summary skill that structures every interview into the same shape — pain points, feature requests, sentiment, competitive tools, follow-ups — so when an agent later goes looking, it finds consistency, not chaos. A refresh-customer-data skill pulls live metrics from our Fabric warehouse into the same folders.
The outcome: when an agent is asked to write a PRD, draft a one-pager, or run a design-readiness check, it doesn’t need to invent a user. It can cite Diligent Dan (a fleet operator) by name, point to the specific Woolworths call where the pain came up, and link back to the relevant strategy document. Customer truth becomes addressable.
Pulling all this information into one place wasn’t just a documentation exercise. It’s the move that lets the next four sections work. Without addressable customer evidence, every gate downstream would collapse into hand-waving.
Design intent was lost in the build
Even with great knowledge and customer evidence, the next failure mode showed up immediately: design intent didn’t show up in the build. Engineers, and now agents, would avoid asking design for help. Instead, they dove immediately into the code. Even when a Figma file was available, they’d look at a frame and infer the what, but not the why. With agents accelerating implementation, the lossiness compounded. A small ambiguity in week one quickly became a misaligned feature by week three.
The fix was to make design intent an artifact, not a vibe. We collaborated on a skill in the engineer’s Agentic Framework called first-principles. It runs before any code is written, and it forces the agent (or the human running it) to write a structured intent definition for each feature ticket or epic. The sections are non-negotiable: who, why now, success metrics, trigger, the flow, errors and edge cases, platform fit, principles applied, open questions.
The strongest design choice in the skill is what it refuses to do. Hedging is how design intent quietly disappears in agentic systems and how ambiguity ships. By making the agent refuse to hedge, we force the question back to a human: the engineer, the designer, or the PM. The ticket that comes out the other side is honest: either a clear contract for what we’re building, or a list of named gaps that need answering.
That ticket is then the single thing the implementer agent codes from, and the single thing the design-reviewer agent grades the implementation against. Intent stops being tribal whisper and becomes contract.
Definition of Ready was implicit, so agents skipped it
Design intent only helps if the ticket was worth writing intent for in the first place. Plenty of tickets enter any backlog without enough customer evidence, without a persona, without a clear success metric, or without thought to accessibility or edge cases. We historically caught this as designers embedded in the teams, but in a 2-person team across an org with 20 engineers and several PMs, this didn’t scale.
Our second design gate is design-readiness. It runs at intake, before a ticket for a major feature change can enter the implementation pipeline and validates nine dimensions:
- Problem statement
- Persona
- Customer evidence
- PRD link
- Success metric
- Error and edge cases
- Platform fit
- Design assets reachable in Figma
- Accessibility considerations
It returns a structured verdict: PASS or BLOCK, with a gap report. Wired into the orchestrator intake flow, a BLOCK halts the pipeline. No implementation, no code-writing agent, or PR. The ticket writer must close the gaps by adding the missing evidence into the ticket, using an agent to find it in Beacon or asking design. If there aren’t clear answers, the feature won’t be built.
The leverage here is enormous. Two designers can’t sit at the front of every ticket, but the agent can. And because the gate is a deterministic checklist rather than a vibe-based review, it’s consistent across PMs, engineers, and squads. Our 2-person design team discipline now travels with every ticket, automatically.
Design review didn't scale to agent throughput
The final failure mode is the obvious one: even when designers are involved, review happens too late, too unevenly, and on too few PRs. With agents shipping more PRs than a human team can manually pick up, the review queue started to get worse, and design quality eroded fastest in the last ten percent of implementation.
So we added the third design surface: a ‘design-reviewer’ agent in the Agentic Framework. It runs in the review phase of the orchestrator, in parallel with the ‘code-reviewer’ and ‘security-reviewer’. Its inputs are the design intent and the design guidelines and principles in Beacon. Its job is to grade the implementation against the contract the in the design intent, the named patterns it referenced, and our seven design principles in priority order.
Three things make this work where past “design review at PR time” has failed:
- The contract. The reviewer doesn’t ask “is this good?”. It asks “does this match what the intent doc promised?” The bar is specific, not aesthetic.
- The fan-out. Code, security, and design reviewers run in parallel, and the orchestrating agent synthesises their findings. Design no longer waits behind the back-end review.
- Non-deferrable findings. In the framework’s review pattern, every issue is mandatory. Nothing gets quietly deferred to a “next iteration” that never comes.
Outcomes
What changed structurally: Beacon now hosts over 300 files of product, design, customer, engineering, and team-process knowledge. Design has three first-class agentic surfaces in the Agentic Framework: design-readiness as the entry gate, first-principles as the intent contract, and a design-reviewer as the parallel reviewer. Each is wired into the orchestrator and runs automatically on UX-impacting tickets.
What changed for the team: PMs and engineers now operate from the same customer evidence and the same design principles as the design team — there is no separate “design source of truth” any more. My team’s leverage extends to every ticket and every PR an agent touches, not just the ones we can personally pick up. The trade-off we used to make of velocity vs. customer-fit discipline is much weaker now, because the discipline is encoded in agent-readable context and gates rather than in human availability.
What’s next: A scheduled daily-news agent that briefs the Product & Tech team each morning on Australian energy and EV news, an MCP server connecting Beacon to user data in Amplitude, and an Ask Beacon chatbot to extend our customer focus to the rest of the org. Each is another way to push customer reality further into the agentic loop.
As we’ve built agentic development at JET Charge, I’ve found it doesn’t make design less important. It makes design more important, because the cost of unclear intent, unaddressed customer feedback, or skipped reviews now compounds at agent speed. The work in this case study isn’t really about tools — it’s about shifting design from a slow, embedded service into a whole-org infrastructure that the entire team and its agents can stand on. That shift is what lets a small design team scale.