B2B Agentic Workflow: ASTRA

Claude Design Agents · Agricultural Platform · Web · 2026

Business Context

Astra Agro sells Fendt, Valtra, Manitou, and Horsch equipment across multiple regional offices, with a lead-capture form on every product page. Every lead lands in a shared inbox with no regional ownership and no visibility for leadership. Solving that meant building a platform where four distinct roles — Regional Manager, Finance Coordinator, Service Dispatcher, National Admin — could each move quickly without waiting on each other. That need for real speed is what led me toward an agentic workflow.

Speed and Quality

Platforms like this usually take months — designing screens, building and maintaining a consistent design system, keeping four different workflows from drifting apart as each gets built separately. Astra Agro didn't have that runway. The real constraint wasn't the interface itself, it was speed: could a rigorous, on-system, accessible product actually get built fast, without quality being the thing that quietly gets cut to hit the deadline?

Two Agents, Not One Designer

Rather than one general-purpose agent, I built two specialized ones. A design-system agent works directly in Figma — extending tokens, building components, checking accessibility. A second agent builds pages from an approved spec, checking each new screen against what's already built so it stays consistent. Together, they let one designer move at team pace, without design discipline being the first casualty of the deadline.

Dealer Operations Console is an internal platform for Astra Agro, a multi-region agricultural equipment dealer, giving regional managers, finance coordinators, service dispatchers, and leadership a fast, purpose-built way to work with leads generated by the public site. Building four genuinely different role-based experiences at the speed the business needed meant rethinking how the work itself got done — I designed and led the platform using a two-agent AI workflow, covering everything from the design system to the pages built on top of it.

I worked directly with the client to understand the requirements — particularly how role-based access needed to work across the four operational roles, since that shaped nearly every downstream decision. I owned the design system and the HTML prototypes, building both through a two-agent workflow: one agent maintaining the Figma design system and documenting it into a spec the second agent could actually build from, the second building the pages themselves. As pages moved toward implementation, I worked with the front-end developer directly, resolving discrepancies between what the agents had generated and what he actually needed to build it for real.

My Role

Mapping Role Permissions

I worked directly with the client to understand the requirements — particularly how role-based access needed to work across the four operational roles, since that shaped nearly every downstream decision. I owned the design system and the HTML prototypes, building both through a two-agent workflow: one agent maintaining the Figma design system and documenting it into a spec the second agent could actually build from, the second building the pages themselves. As pages moved toward implementation, I worked with the front-end developer directly, resolving discrepancies between what the agents had generated and what he actually needed to build it for real.

Regional Manager

Finance Coordinator

Lead Response. Review new leads in their region, understand what the person is asking about, and respond with the right brochure or technique link for their stated interest.

Financing Handoff — Flag a lead as loan- or rental-interested and route it to the Finance Coordinator with the context already attached, rather than the lead starting over.

Bank Matching — Review a flagged lead's situation and identify which partner bank's financing program actually fits their case.

Partner Documentation Lookup — Check a bank's current loan or credit terms mid-conversation with a lead, without leaving the platform to dig through separate files.

Service Dispatcher

Service Request Assignment — Review new maintenance/repair requests from existing customers and assign the right technician by region.

Equipment History Check — Pull a client's service history before dispatching, so the technician isn't walking in blind to a recurring issue.

Spec-Driven Development: One Source of Truth for the Whole Team

Each task from the role workshop became one spec entry: who does it, what they see, what they can change and what counts as done. The Regional Manager's financing handoff, for example, was a single entry, with the requirement that the lead arrives at Finance with its context already attached. Developers and I used the same role and task names, so no one had to translate between documents.

What a spec actually held

We ran Astra on spec-driven development (SDD). Every screen, state and permission was written down as a spec before anyone designed or built it, and that spec stayed the reference for the whole team. The business analyst, the manager, the front-end developers and I all worked from the same document instead of from our own interpretations of the requirements.

My role: from spec to functional prototypes

Every prototype screen traced back to a spec entry, and I built it in working HTML so the behavior could be tested, not just looked at. When the interviews showed something the spec lacked, I took it back to the spec first. Finance Coordinators told me bank terms change often and can't live in a static PDF, so "current terms, in the platform" became a requirement before it became a screen.

Handoff to development

Developers received something they could open, click through and inspect, along with the tokens and component rules behind it. Questions came back as spec changes, not as one-off fixes. That kept design, analysis and code describing the same product.

Deliver Fast Without Losing Consistency

The workshop defined exactly which roles and access Regional Managers would have. The business analyst turned those results into the part of our large SDD document that covers them: the Leads tab and its leads table. This was the spec I received, written at the level of business requirements.

Workshop ➔ BA Spec

BA Spec ➔ Technical Spec

I turned the BA spec into a technical one using Claude Code, which already had access to my project folders and the design system's Markdown files. The technical spec names real components and states, sets validation rules, and covers failure cases such as a message that doesn't arrive or a lead a colleague is already handling.

Pages Built + Design System Growth

I ran the technical spec to generate the actual pages. Whenever a page needed something the system didn't have yet, my design system agent added it first. It checked accessibility and color contrast and kept every component on the existing tokens and text styles. I stayed the owner of the system and approved each addition before it was documented.

.md file exmaple:

Organizing folder and .md files

Every role in Astra ships as two linked sets of files: Markdown specs and HTML pages. The Regional Manager’s Leads page is the clearest example. Its page spec describes the leads table, the lead’s request and the response form. Behind it, the design system specs document every component the page uses: 19 atoms and 9 molecules, each with its Figma node, its variants, every state and the tokens it binds to. The prototype agent reads those files and builds the page as one self-contained HTML file, styled through the same token names as Figma. Below are a few component specs, then the Leads page they produce.

Folder structure:

Generated HTML pages

The pages were generated by my HTML agent, which read the Markdown specs and built each screen from them. These were quick first prototypes, written from the descriptions, because we were short on time. The system was first launched for just a few employees, so we released it as it was and treated it as a test case. As the design system grows, the next steps are tighter accessibility checks, closer monitoring of the user flows, and more precise pages.

Ongoing Project

Astra is a live project, and we’re still learning as we go. Next I’ll design the screens for the two remaining roles, the Finance Coordinator and the Service Dispatcher. Their work calls for more complex components than a leads table, such as comparing two banks’ terms side by side, or checking which technician is available in a region before assigning a job.

I’ll keep working closely with the developers so the specs, components and pages stay in step with what actually gets built. New people will join to test the pages with real tasks and help us improve accessibility.

Let's connect!

adolphina13@gmail.com