Most AI coding tools stop at the blinking cursor.
They autocomplete a function. They rewrite a file. They leave you staring at a green diff and a quiet doubt: Will this survive review? Will CI pass? Will the real journey still work after deploy?
We wanted a different experiment.
What if the AI didn’t just write code—what if it could own the ticket? Plan it. Argue with itself about the design. Write the behavioural contract. Implement. Review. Build. Deploy to a validation environment. Read the failing tests. Fix. Learn. Then hand humans a pull request with receipts.
That system is Exotel’s AI Developer.
It is a hosted delivery loop that lives inside the tools we already use—Jira, Bitbucket, CI, QA environments—and leaves evidence everywhere it goes. Engineering judgment stays with people. Production release stays with people. The agent’s job is to carry the ticket through the hard middle.
Start with a ticket
The interface is deliberately boring. That is the point.
A product engineer opens a normal Jira ticket. They write acceptance criteria the way they would for any teammate. They add a label. Work begins.
The workflow stays inside tools the team already knows how to operate. There is no special console or separate AI portal to learn first.
If someone needs to steer the run, they do what they already do: comment on the ticket, leave a PR review, ask for a rebuild, request revised test cases. The AI Developer resumes from that signal.
Jira is the inbox. Pull requests are the negotiation table. CI and validation environments are the truth machines.
The story of one ticket
Imagine a Monday morning change: a Voicebot flow needs a new branch of behaviour. The requirement is clear enough to start, messy enough to be real.
Here is the path the ticket walks:
Label → Plan → E2E cases → Code → Review → Build → Deploy to validation → Run tests → Diagnose failures → Learn → PR + Jira handoff
That sequence is the whole product thesis. Generation without verification is cosplay. Verification without a plan is thrash. A plan without a behavioural contract is hope dressed as engineering.
Meet the crew (none of them touch production alone)
Think of the AI Developer as a senior engineer who refuses to do everything personally.
They coordinate a crew:
- The Architecture Agent reads the ticket, explores the repos, and writes the plan—or stops and asks a clarifying question when the requirement is fog.
- The E2E Test Case Agent turns acceptance criteria into reviewable scenarios before anyone starts typing implementation code.
- The Coding Agent makes the change.
- The Code Review Agent tries to break the author’s confidence on purpose.
- The Build Workflow runs the same CI gates humans already use.
- The Deploy and Test Workflow promotes successful artifacts into a controlled validation environment and runs journey-level checks.
- The Test Result Analysis Agent reads reports, logs, and artifacts when something fails, then returns with a diagnosis.
- The Learning Agent captures what should outlive the ticket and help the next one start faster.
One agent that plans, codes, reviews itself, deploys, and declares victory is how you manufacture elegant mistakes. Separate phases create places for reality to interrupt.
First, write the map
Every new ticket starts with planning. The Architecture Agent does the unglamorous work: which services move, which repositories matter, what depends on what, where risk hides.
If the ticket says “support X” but never defines failure behaviour, the agent pauses and asks. On Jira. In public. Where a human can answer once for the whole team.
Ambiguity should be loud. Silence is how wrong systems get built with perfect grammar.
Then write the contract—before the code
This is one of our favourite design choices.
After a viable plan exists, and before implementation, the E2E Test Case Agent authors the behavioural contract: happy paths, negative paths, edge cases that actually matter, priorities that separate must-pass journeys from nice-to-have ones.
It pulls from the ticket, acceptance criteria, comments, and linked product docs. Screens, APIs, and copy have to come from something someone wrote. When something is missing, the agent says so in the notes.
Those cases land in a shared, ticket-scoped sheet. Product managers and QA can skim them early. If the cases are wrong, humans @mention the agent and ask for a rewrite. The code has not calcified around a misunderstood requirement yet.
In other words: we try to agree on “done” while the clay is still soft.
Code and critique in the same conversation
Only then does implementation begin.
The Coding Agent changes the repos. A separate Review Agent reads the diff like a sceptical teammate: Is this the right place? Is the blast radius honest? Did we paper over the edge case we promised in the sheet?
Findings go back. Fixes come forward. The loop runs until approval—or until bounded limits say “stop romanticising another iteration and escalate.”
Later, when a human leaves PR comments, the same loop wakes up again. Context stays with the ticket and the PR. The instruction is simple—“Address the review”—and the agent fetches the comments like any engineer would.
CI is an argument
A pretty diff still has to survive the pipeline.
Once review approves the change, the Build Workflow triggers the real CI pipelines for the branches that moved. Same Jenkins and quality gates our engineers already trust. Compilation, automated checks, coverage—whatever the pipeline already encodes as “this is allowed to continue.”
If CI fails, the failure becomes structured feedback for the coding loop. Fix. Rebase if needed. Rebuild.
There is a ceiling on retries. Endless self-healing is just infinite flailing with better marketing. When the ceiling hits, the ticket gets an honest failure state and a trail of evidence.
Deploy closes the gap between “green” and “real”
Passing CI means the change survived the pipeline. Five services, a network boundary, and a flaky integration still have to tell a coherent story together.
So the Deploy and Test Workflow takes the successful build versions, prepares a controlled QA environment, deploys the affected services, and runs the available sanity and E2E suites. Reports and artifacts come back as reviewable proof.
Teams adapt the workflow to their own deploy topology and test suites, but the contract stays stable:
- Deploy the exact artifacts that just passed CI.
- Exercise the journeys promised by the behavioural contract.
- Capture evidence when reality disagrees.
- Return a structured result the coordinator can act on.
Production release stays human. Full stop. The agent’s job is to prove the change in a realistic validation environment and prepare the case for reviewers.
When tests fail, investigate
A red suite without diagnosis is just expensive noise.
The Test Result Analysis Agent opens the report, correlates logs and artifacts, compares expected versus actual behaviour, and asks the uncomfortable question: Is this an application regression from the ticket, a flake, an environment scar, or a stale assertion?
Then it proposes fixes with confidence levels and evidence. Those findings return to implementation and review. Another build. Another validation pass.
Deploy and test stop being a ceremony at the end of the parade. They become part of the argument the system is having with itself.
One laptop per ticket (metaphorically)
Parallelism without isolation is how you invent ghost bugs.
Each active ticket gets its own workspace—repos, branches, local state—like lending an engineer a dedicated laptop for the job. A pool limits concurrency. A queue holds overflow. When the run ends, the workspace is released and the next ticket can start.
It is unglamorous infrastructure. It is also what lets agents run side by side without stepping on each other’s toes.
Memory that survives the merge
The expensive part of software is rarely typing. It is rediscovery.
After a successful cycle, the Learning Agent looks for lessons that should outlive the ticket: where a responsibility actually lives, which integration constraint keeps biting teams, which journey must stay protected. It proposes documentation updates through normal pull requests.
Learning is best-effort. A docs miss leaves a valid build intact. When learning works, the next agent—and the next human—starts less lost.
Humans own the loop
We like the phrase “human-in-the-loop,” but it undersells the point.
People still decide whether the plan is sane. Whether the E2E cases match the product. Whether the PR is mergeable. Whether production should move.
Their actions look ordinary on purpose:
- Label a ticket to start.
- Answer a clarification on Jira.
- Review the plan and the behavioural sheet.
- Comment on a PR like any other PR.
- Ask the agent to revise cases, fix code, rebuild, or re-validate.
- Approve merge and production release through existing controls.
When the run finishes, the ticket gets a summary with phases, build and validation results, test evidence, PR links, and next steps. The completion is boring in the best way: inspectable, linkable, and easy to challenge.
Knowing when to stop is a feature
Autonomy without brakes is just a very fast way to dig a hole.
The AI Developer exits when requirements need clarification, when review or build loops hit their limits, or when something unrecoverable happens. Best-effort stages are reported honestly. Every run leaves an audit trail.
A useful agent acts, asks, retries with a budget, and stops with dignity.
What we’re building next
The complete flow is the foundation. The roadmap is about making it sharper as more teams adopt it:
- Readiness before planning — ask product and architecture questions earlier, so we stop planning tickets that were never implementation-ready.
- Blast-radius analysis — know which services, repos, and operational risks are in play before the first line changes.
- One quality path — run the same review and E2E agents on human-authored and AI-authored work, so corrections improve a shared system.
- More executable E2E — keep turning reviewable behavioural cases into suites that run after deploy.
- Smarter routing — send tickets to product-bounded workspaces with the right context as adoption grows.
- Cross-workspace learning — carry useful lessons across related services without dumping irrelevant noise everywhere.
- Richer deploy evidence — stronger health checks, observability, and rollback guidance, still with humans owning production.
The aim is a shared evidence-driven road for human and agent work: a clear requirement, a plan you can argue with, a behavioural contract, independent review, real CI, controlled validation, diagnosis when reality bites, learning that sticks, and a release decision that still belongs to people.
That is what “owning a ticket” should mean.
And that is the system we are building at Exotel.