From Epic to Production: Using Agents to Deliver Features in Real Systems

This is the eighth article in the series about AI-friendly architecture. In the previous articles, we talked about context, documentation, observability, skills, Context Skills, agents, tools, MCP, guardrails, and harnesses.

Now we will bring these pieces together in a complete engineering workflow.

The idea is not to ask an agent to “implement a feature” and expect it to discover everything by itself. The goal is to show how an agent can help with a delivery from the moment we understand the epic until we monitor the change in production.

Writing the code is only one step. In many cases, it is not even the hardest one.

The epic

Let us use this request as an example:

As a customer, I want to request a partial refund for an order,
so I can return only some of the items I bought.

At first, this looks like a small change in the payment service.

But before writing code, we need to understand several things:

• where the order is created;

• who calculates the total amount;

• which service owns the payment;

• how items are linked to the transaction;

• which cancellation rules exist;

• how inventory is updated;

• how the customer is notified;

• which data must be sent to the payment provider.

An agent that receives only the epic can produce a plausible solution that is still wrong.

Question the epic

The agent's first job should not be creating files. It should be turning the epic into questions.

Possible questions include:

• What business problem are we trying to solve?

• Who can request a refund?

• Which items are eligible?

• Is there a time limit for requesting a refund?

• Can an order have more than one refund?

• How do we handle a partial refund that has already started?

• Is the refund amount calculated from the order or from the payment?

• What happens if the payment provider accepts the refund but the internal update fails?

• Should inventory be released immediately or only after confirmation?

• How will the customer be informed?

The agent does not need to answer everything by itself. Its job is to take the right questions to the product owner and the teams involved.

Questioning the epic does not block the work. It turns unclear points into explicit decisions before they become bugs or rework.

A planning skill can guide the creation of these questions. The agent can check domain documentation and use a tool to find epics, requirements, and previous decisions.

Run the spike

After the goal is clear, the technical investigation begins.

The agent can use different Context Skills to investigate the problem. An order skill helps it understand order items and states. A payment skill explains the provider's rules. An observability skill shows how to investigate the current behavior.

The goal of the spike is not to produce a nice answer. It is to build a view based on evidence.

The agent can look for:

• code related to the order;

• the current cancellation flow;

• the payment provider integration;

• refund or cancellation tests;

• events published after a payment change;

• consumers of those events;

• ADRs and previous decisions;

• metrics and traces for the current flow;

• related incidents.

A reasonable investigation could follow this order:

1. Find the order model or contract.

2. Find the current cancellation flow.

3. Find the payment provider integration.

4. Find refund or cancellation tests.

5. Find events published after a payment change.

6. Find the consumers of those events.

7. Check production signals to understand the current behavior.

The agent should not only find files with similar names. It needs to rebuild the flow and explain how the parts are connected.

Record the spike decision

The result of the spike should not remain only in the conversation history. It should become documentation that can be found during future investigations.

A decision document could look like this:

# Decision: partial refunds

## Context

An order can contain several items, but the current refund flow
works only with the total transaction amount.

## Options considered

- create a new transaction type;
- allow multiple refunds on the existing transaction;
- create a separate refund service.

## Decision

Use the existing transaction and track the total refunded amount.

## Consequences

- the external provider must support multiple refunds;
- the refund event must identify the items;
- the operation must be idempotent;
- old consumers must keep working.

## Risks

- two refund requests may run at the same time;
- the external and internal states may become different;
- some consumers may not know the new format.

This documentation helps the current team, but it also helps future agents and future work.

Every well-documented spike adds a new context source to the architecture. Over time, we stop depending only on code and build a map of decisions, contracts, and consequences.

Define what success means

Before creating tasks, we need to answer one simple question:

How will we know that this implementation solved the problem?

For a partial refund, success may mean:

• the customer can select eligible items;

• the refund amount never exceeds the amount paid;

• the same request is never processed twice;

• the provider receives the correct data;

• inventory is updated at the right time;

• the customer receives a clear notification;

• old consumers keep working;

• the error rate does not increase;

• latency stays within the expected limit;

• the number of partial-refund support requests decreases;

• the operation can be investigated later.

These criteria matter more than the number of changed files. Implemented code does not automatically mean that the problem was solved.

We also need to measure the impact outside the system. If the goal is to let customers request partial refunds by themselves, fewer support requests about this process may be an important success metric.

This metric should be combined with technical signals. Fewer support requests are a success only if the error rate did not increase and refunds are being processed correctly. Otherwise, we may only be making the problem less visible to support.

That is why the definition of success should already point to observability work. These criteria must become metrics, queries, dashboards, and alerts.

Define and create the tasks

With the decisions and success criteria defined, the agent can break the delivery into tasks:

• add the partial-refund endpoint;

• validate items and the total refunded amount;

• update the provider integration;

• ensure idempotency and concurrency control;

• version the payment event;

• update inventory and notification consumers;

• create unit and integration tests;

• configure the QA environment;

• add metrics and traces;

• create dashboards and alerts;

• update the documentation and runbook.

A tool can create these tasks in the system used by the team. A planning skill can define the minimum format for each task, including context, acceptance criteria, dependencies, and risks.

The agent can prepare the tasks, but the team must still confirm that the split correctly represents the work and ownership of each domain.

Define how to test

Before implementation, we need to decide how to validate the change in a non-production environment.

This may involve:

• test data for orders with several items;

• a simulated payment provider;

• a feature flag for gradual rollout;

• a QA environment with updated consumers;

• contract tests for events;

• concurrency tests;

• idempotency tests;

• failure tests after external confirmation;

• rollback tests.

The agent can create test scenarios from the success criteria, but the team must check whether the environment can reproduce the important conditions of the real system.

A good question is:

What must be configured in QA for us to trust the result?

If the answer is “nothing,” the test has probably not been defined well enough.

Define observability before the code

Even before AI tools existed, it was good practice to decide how a change would be observed after release.

For each feature, we need to decide:

• which logs will be emitted;

• which metrics will be collected;

• which traces must exist;

• which queries will be used;

• which behavior means success;

• which behavior means degradation;

• which signal should start a rollback.

For partial refunds, we could track:

• the number of started requests;

• the number of confirmed refunds;

• the number of provider failures;

• the total refunded amount;

• the time between request and confirmation;

• differences between external and internal state;

• the number of retries;

• failures by provider or payment method.

The agent can help write queries and configure dashboards, but deciding what to observe is an engineering decision. Without this work, the team can release the change and have no evidence that it worked.

Implement the code

Only now does implementation begin.

The agent can help to:

• create or change classes;

• update contracts;

• write tests;

• change schemas;

• add instrumentation;

• update configuration;

• prepare a pull request.

But it is important to understand the size of this step. Implementation is only one part of the cycle.

Understanding the problem, making decisions, defining success, preparing the environment, choosing signals, and planning operations may require more reasoning than writing the code itself.

The agent becomes more useful when it takes part in all these steps, not only when it receives a file to modify.

Create dashboards and alerts

Before the deployment, we need to prepare the operation of the feature.

This may include:

• a dashboard for the new flow;

• success rate;

• error rate;

• latency;

• request volume;

• impact by customer or region;

• failures by dependency;

• state-mismatch alerts;

• error-increase alerts;

• rollback criteria.

A dashboard without a clear operational question can become decoration. Each panel should help answer a question such as:

• Is the feature being used?

• Is it working?

• Is it slower?

• Is it affecting another context?

• Do we need to stop the rollout?

Deploy and monitor

The agent can prepare the pull request, the change record, and the deployment plan. It can summarize risks, list checks, and organize the steps.

Production execution must still follow the organization's policies. Depending on the risk, a person may need to approve the change record, review the pull request, and authorize the merge.

After deployment, monitoring should compare the observed behavior with the previous baseline:

• Are the metrics within the expected range?

• Has the error rate changed?

• Is the provider responding as expected?

• Are events being consumed?

• Do the dashboards show the result defined at the start?

• Does any alert need to be triggered?

The agent can check the signals and organize the analysis. The decision to continue, pause, or revert the change must follow the limits defined by the team.

Finish the delivery with documentation

The delivery does not end when the deployment is complete.

The document created during the spike should be updated with the real implementation result:

• what was implemented;

• which decisions changed;

• which contracts were versioned;

• which metrics were created;

• which alerts exist;

• how to operate the feature;

• how to investigate failures;

• which limitations remain;

• which lessons can be reused.

This closing step creates a learning cycle:

1. The epic creates questions.

2. The spike creates a decision.

3. The implementation creates new behavior.

4. Operations creates evidence.

5. Documentation records what was learned.

6. The next request starts with more context.

This is how a Context Architecture really grows. It is not a document created once. It is a body of knowledge that grows with the system.

Where do skills, tools, and MCP fit?

Each step can use a different combination:

• Planning Skill: questions the epic and breaks down the work;

• Architecture Skill: checks decisions and identifies impacts;

• Testing Skill: defines scenarios and validation strategies;

• Observability Skill: creates queries, metrics, and dashboards;

• Delivery Skill: prepares the pull request, change record, and deployment;

• Tools: perform specific actions, such as finding documents or creating tasks;

• MCP: connects the agent to the systems where these actions happen.

The agent coordinates the workflow, but it does not need to carry all knowledge from all contexts at the same time. Each skill provides a specialization, and each tool performs a concrete capability.

The role of human review

The goal is not to remove the team from the engineering process.

The team still needs to:

• confirm business rules;

• evaluate trade-offs;

• approve contract changes;

• decide which risks are acceptable;

• approve production changes;

• take responsibility for the decision.

The agent helps make preparation faster and more complete. It can move through different sources, find relationships that might be missed, and organize evidence in a format that is easier to review.

The decision remains the team's responsibility.

Conclusion

An agent can take part in the full life cycle of a feature without starting by writing code.

It can question an epic, run a spike, record decisions, define success criteria, create tasks, plan tests, prepare observability queries, implement changes, open a pull request, monitor a deployment, and update documentation.

This workflow works well only when context is available, connected, and reliable. Without documentation, decisions, observability, and skills, the agent tends to fill gaps with guesses.

With an AI-friendly architecture, the agent can work with evidence and make it clear what it knows, what it inferred, and what still needs to be decided.

This is where the conversation stops being only about generating code. The agent starts to take part in the engineering work that happens before, during, and after implementation.