# Secret Agent: from requirements to production

Author: [Sahil Bambulkar](https://www.sahilbambulkar.com/career/)
Published: 2026-10-25T22:23:49Z
Canonical URL: https://www.sahilbambulkar.com/blog/secret-agent/

**Internal Amazon project · confidentiality.** This is a high-level personal account. User counts, detailed business impact, and internal implementation details are withheld. Deeper technical discussion requires internal approval. Views are my own and do not represent Amazon.

## At a glance

- Secret Agent takes documents and requirements through a visible, stage-by-stage workflow.
- Missing decisions and manual tasks become blockers assigned to the relevant stakeholder.
- A major project reached production with limited manual intervention; business-impact figures remain confidential.

A project manager should be able to refine a requirement without manually carrying that change through every tool and every stage of delivery.

## The problem was the distance from a requirement to a release

The motivation for Secret Agent came from frequent requirement changes. Our partner would refine what was needed. Internal project managers would add or adjust requirements as the project evolved. Each change then had to make its way through a chain of manual handoffs.

Agents could already help with individual tasks, but the surrounding workflow was not completely agentic. People still had to move context between tools, notice missing information, find the right stakeholder, and work out what could happen next.

I wanted a unified platform where a project manager could refine the requirements and see that work move toward production, with the exceptions made visible rather than hidden in a series of disconnected conversations.

## Begin with the documents, and expose the gaps

Secret Agent takes in the relevant documents and requirements. Its operating principle is to avoid silently inventing missing requirements. If the work cannot proceed because an answer or action is missing, that limitation becomes a visible blocker in the workflow.

This distinction matters. An unclear product decision is not something a coding agent should resolve merely because it can produce plausible code. The platform needs a way to ask the appropriate person and then continue with the answer.

## Keep the workflow above the individual CLI

The orchestration layer can drive work through coding CLIs such as Claude Code, Kiro CLI, Codex, or Cursor CLI. The useful abstraction is the stage of work and its requirements, rather than tying the entire process to one tool.

An agent runs until it reaches a limitation it cannot complete on its own. The interface then asks the appropriate stakeholder for feedback or identifies a manual task. The stakeholder can provide an answer, involve others through a Slack integration, or confirm that a required action is complete.

Requirements → Agent work → Verify → Production

When blocked: ask the responsible stakeholder → record the answer or completed action → resume the stage

A high-level view of the workflow, including the human decision point. This is not an internal architecture diagram.

## Make the next action visible

The UI presents the process stage by stage. A blocker is attached to the person or group that needs to act. Once the missing answer is supplied, or the manual step is marked complete, the workflow can continue to the next stage.

The purpose is not to hide the remaining human work. It is to make that work precise: what is needed, who can provide it, and which stage is waiting for it.

A requirements change can enter through the same platform rather than becoming another piece of context that someone has to remember to forward. That gives project managers a more direct way to participate in the delivery process while retaining the decision points that require their judgment.

## What the proof of concept delivered

The platform successfully took a major project from requirements to production with very limited manual intervention. A few limitations around email templates still required manual work. I would describe the result as autonomous progression through the supported stages, with explicit handoffs where the system reached those limitations.

The proof of concept was motivated by leadership, including an L8 sponsor, and demonstrated the value of connecting agent execution to a complete delivery workflow.

Delivery-time reduction

\[weeks withheld\]

Increase in emails sent

\[volume withheld\]

The exact business-impact figures are confidential. The result I can discuss is that a major project reached production through this workflow and showed a practical path from requirement refinement to agentic delivery.

## What I learned

The coding agent is only one participant in a project. Requirements, approvals, manual tasks, and feedback all influence whether the project can ship.

Secret Agent’s value came from treating those dependencies as part of the workflow. When an agent can proceed, it proceeds. When it cannot, the platform makes the missing decision visible to the person who can resolve it.

## About this account

This is my high-level description of an internal agentic workflow-orchestration platform. Internal documents, service architecture, user counts, and business-impact measurements are not included. Further technical discussion requires internal approval.
