From Stakeholder Meeting to Working Software: An AI-Assisted Delivery Workflow

Context

I am designing and delivering a new internal Event Management System for a team whose work has accumulated the usual layers of manual coordination.

Event forms and layouts are created and managed by hand. Employee information and VIP guests require manual handling. RSVP confirmations are inconsistent. Event administrators spend meaningful time moving information between people and tools instead of operating events.

The first release is deliberately smaller than the full problem:

• Employees can discover and register for events.
• Administrators can create and schedule events.
• Event staff can check attendees in.

Some events also include spouses or children, which makes registration more than a simple employee-to-event relationship.

The product is still in progress. This is not a victory lap with adoption charts and a suspiciously round productivity percentage. It is a case study in how I am turning an ambiguous internal need into working software—and how I am using AI agents as role-bounded “tiny teams” without handing them ownership of the product.

Why this is more than a CRUD app

At first glance, an event system sounds straightforward: create events, collect registrations, and record attendance.

But the difficult questions are not about forms and database operations.

Who is eligible to register? Which employee attributes belong to the application? What happens when an employee registers a family member? Who can prevent someone from registering, for how long, and what restores eligibility? Which system is authoritative when identity data and employee data disagree?

The interface may eventually look simple because those decisions were made carefully. Simplicity in the product does not mean the domain was simple. It often means someone did the work of removing ambiguity before it reached the screen.

Defining the MVP around complete workflows

The initial scope is organized around three actors and three complete outcomes: an employee registers, an administrator creates and schedules an event, and event staff check someone in.

That boundary matters. A longer feature list could create the appearance of progress while leaving the core workflow unusable end to end.

The MVP also includes the minimum supporting rules those outcomes require. Family events must support known dependents. Administrators need employee lookup. A time-bound restriction must prevent registration across events and then expire automatically.

When a requirement includes a limit or duration, I do not assume the value is permanent or universal. I ask who controls it, whether it varies by situation, and what happens when the period ends. “Blocked for 30 days” sounds like a rule. It may actually be a default, an administrator decision, or a placeholder that escaped a meeting.

Identity is not application-owned employee data

The application uses single sign-on. SSO supplies useful identity context: employee ID, department, location, name, and work email.

Availability is not ownership.

I deliberately do not want to persist every attribute SSO provides simply because it is convenient. Authentication answers who is present and provides context for the session. It does not automatically become the authoritative source for every employee record the product needs to operate.

For persisted employee information, the application uses the organization’s HR system of record. That data supports application workflows such as administrator lookup and employee blacklisting. The distinction gives each field an explicit authority rather than allowing whichever integration returned a value first to become the accidental master.

Three principles guide this part of the design:

Don’t ask users to re-enter information the organization already knows.

Authentication data and application-owned data are not the same thing.

For each important field, identify the system that is authoritative for it.

Legacy dependent information will also be migrated so employees do not have to repeatedly register spouses or children. That is partly a usability choice, but it is also a data-continuity decision: existing organizational knowledge should survive the replacement of the tool that currently exposes it.

Blacklisting is modeled as a restriction with an administrator-defined expiration date. Eligibility resumes through system rules after that date rather than depending on someone to remember a cleanup task. Time-bound business restrictions should expire because the rule says they have expired, not because an administrator happened to revisit a queue.

Turning conversations into requirements

The project begins with stakeholder conversations, not tickets.

After each meeting, I use the transcript to extract candidate requirements, decisions, assumptions, and unresolved questions. An AI agent helps identify gaps: missing actors, undefined permissions, unclear exception paths, and rules that sound precise but are not yet testable.

The output is not treated as approved truth. It becomes a structured review artifact.

I validate it against my notes, decide which gaps matter, and bring follow-up questions back to stakeholders. This creates a useful loop: each conversation improves the product definition, and each artifact makes the next conversation more concrete.

The workflow looks roughly like this:

Stakeholder meeting
        ↓
Meeting transcript
        ↓
Requirement extraction
        ↓
Gap analysis and follow-up questions
        ↓
Prototype and Jira backlog
        ↓
Architecture decisions
        ↓
Developer agent
        ↓
Reviewer agent

The diagram is linear because diagrams are optimistic. In practice, prototype feedback changes requirements, architecture exposes missing decisions, and implementation sends questions back upstream. The important property is not linearity. It is traceability between the artifacts.

Prototyping before polishing

After the first stakeholder meeting, I did not begin with a set of static design screens. I built a working web prototype.

That was not a judgment about design tools. It was a judgment about the question I needed to answer.

At that stage, stakeholders needed something tangible enough to expose misunderstandings. A functioning prototype made navigation, terminology, workflow order, and missing states discussable. People react differently to a process they can click through than to a list of requirements they have already read three times.

The prototype is both a UX artifact and a requirements-discovery tool. It is intentionally allowed to be wrong quickly. Its job is to improve the conversation before the production implementation makes those misunderstandings expensive.

AI agents as role-bounded teams

I established a coherent project context, then used AI across distinct parts of the delivery lifecycle. The roles include Product Owner, Project Manager, UX Designer, Architect, Developer, and Code Reviewer.

Those labels describe bounded modes of work, not autonomous owners.

I remain accountable for the product decisions, stakeholder relationships, system boundaries, scope, implementation direction, and release judgment. The agents increase leverage within those boundaries.

A requirements agent looks for ambiguity and missing decisions. An architecture workflow evaluates the system implications of stable requirements. A developer agent implements a bounded ticket. A separate reviewer agent evaluates that change against the same requirement and the surrounding codebase.

This separation is useful because each role has a different objective. Asking one general-purpose agent to be product manager, architect, developer, and reviewer in one uninterrupted conversation encourages blurred responsibilities and self-review. Role boundaries make the expected artifact and evaluation criteria clearer.

Role-bounded agents are more useful than asking one agent to perform every delivery role at once.

The agents also share coherent project context and exchange structured artifacts. Requirements inform the prototype. Confirmed decisions become backlog items. Tickets link implementation scope to review criteria. Architecture constraints travel with the work instead of being rediscovered in isolated chat sessions.

AI agents become more useful when they exchange structured artifacts inside a coherent project context.

Jira as the implementation contract

Once a slice of the requirements is stable enough to build, I translate it into a Jira backlog.

For AI-assisted implementation, the ticket is more than a planning unit. It is the scope contract.

The developer agent is explicitly instructed to implement only what the ticket requests. It should inspect the surrounding system, ask when an essential detail is missing, and avoid filling the backlog with speculative improvements disguised as helpfulness.

The reviewer agent then checks the implementation against that same ticket. It is not asked whether the code “looks good” in the abstract. It checks whether the requested behavior exists, whether constraints were preserved, and whether the implementation introduced risks outside the agreed boundary.

Don’t let the coding agent decide scope. Give it a bounded work item, then review against the same source of truth.

This does not make tickets magically complete. If the ticket is ambiguous, automation makes ambiguity travel faster. The human owner still has to decide when a requirement is sufficiently understood to become an implementation contract.

Human judgment is the control boundary

AI can extract candidate requirements from a transcript. It cannot decide whether a stakeholder’s passing comment should become product policy.

It can propose a data model. It cannot own the organizational consequences of choosing the wrong authoritative system.

It can implement a ticket. It cannot decide whether that ticket represents the right product scope.

It can review a diff. It cannot accept the operational risk of shipping it.

The control boundary is not “humans do strategy, AI writes code.” The boundary appears anywhere consequences require context, authority, or judgment.

On this project, I use AI to expand attention, accelerate artifact creation, and pressure-test decisions. I do not use it to outsource accountability.

What I would reuse

This workflow is still evolving, but several practices are already reusable on another greenfield enterprise product:

• Start with stakeholder evidence, then turn it into reviewable requirements.
• Use gap analysis to generate better questions rather than silently completing the story.
• Build a tangible prototype when interaction feedback will clarify the domain faster than polished static artifacts.
• Define an authoritative source for every important category of enterprise data.
• Represent time-bound restrictions as system-enforced rules with explicit expiration.
• Give implementation agents bounded tickets and review their work against the same contract.
• Keep agent roles distinct while letting their artifacts share project context.
• Preserve human decision points wherever scope, risk, or organizational authority is involved.

The intended outcome is a product that reduces repetitive event administration and gives employees a clearer registration experience. Those outcomes have not been proven yet. The system is still being designed and delivered.

What exists today is a more disciplined way to move from conversation to code without pretending that faster artifact creation removes the need for product judgment.

Engineering principles

Product

Build the smallest complete workflow, not the longest plausible feature list.

Data

Do not persist identity context by default. Decide what the application owns and which enterprise system is authoritative for everything else.

Requirements

Use ambiguity to generate follow-up questions. Do not let it become accidental implementation scope.

AI-assisted delivery

Give agents bounded roles, coherent context, structured handoffs, and a source of truth against which their output can be reviewed.

Ownership

AI can increase the amount of work one engineer can reason about and produce. It does not reduce the engineer’s responsibility for deciding what should be built, why it belongs in the system, or whether it is ready to ship.