Not every engineering job starts with a ticket
Most demos of AI engineering tools start the same way. Someone opens a ticket, pastes it into an agent, and a pull request appears. It is a good demo. It is also the smallest part of the job.
Think about where the last month of your team’s work actually came from. Some of it was on the board. A lot of it was not. Somebody noticed the same complaint on three customer calls. Somebody spotted that a library you depend on had quietly shipped a breaking change in a minor version. Somebody read a release note. Somebody had a bad feeling about an export endpoint and went looking.
That work exists whether or not anyone writes it down, and writing it down is usually the bottleneck. The signal arrives, the person who saw it is busy, and it is gone.
What an always-on agent is
An always-on agent is not a chat session. It is a job description: a piece of work stated in plain English, with a set of approved tools and data sources, a model policy, a budget, and a defined point where a human has to look.
Once it exists, it runs. Not when someone remembers to invoke it, but continuously, against the same sources, producing the same shape of output every time.
Six that we run, or get asked for most often:
- Customer intelligence. Reads approved call transcripts, finds the request that keeps coming up, and proposes a roadmap item with the evidence attached.
- Support intelligence. Groups incidents that look like separate tickets and are actually one bug. Raises the bug, sometimes with a draft fix.
- Security. Reviews code, dependencies and release changes, and escalates findings with evidence rather than a CVE number and a shrug.
- Vendor watch. Follows the providers you depend on for releases, breaking changes and deprecations, then maps the impact onto your own code.
- Product research. Watches the technology and supplier landscape you care about, and suggests integrations worth considering.
- Release assurance. Runs tests, security review, documentation checks and release preparation overnight, so the morning conversation starts from a known state.
None of these produce a merge on their own. They produce suggestions, which enter the same triage a ticket does, with the same gates.
The part that makes it safe
Continuous is the frightening word. An agent that runs once, under supervision, is a manageable risk. A dozen agents running around the clock against production data is a different proposition, and it fails in the ways you would expect: cost, access, and nobody being able to say afterwards what happened.
The three things an always-on agent needs are not clever prompting.
A budget that is checked first. Per run and per day, enforced at dispatch. A run that would breach its cap does not start. That is the difference between a cost control and a cost report.
Data access that is granted, not inherited. The customer intelligence agent sees approved transcripts. It does not see the repository. The security agent sees the repository and the dependency graph. It does not see the transcripts. An agent that inherits a person’s access inherits all of it.
An output that is a suggestion, not an action. Always-on agents raise work. People decide whether the work is real. Nothing merges without someone’s name against it, and that holds whether the item came from a board, a customer call or a scanner.
Why this is the whole argument
If agents only ever pick up tickets, what you have bought is a faster implementation step, and the constraint moves immediately to whoever writes the tickets.
The interesting position is one level up: the signals that reach engineering, from support, from customers, from security, from your suppliers, all arriving in one place, all turned into governed work, all visible in the same queue with the same gates and the same audit trail.
That is a different product from a coding assistant, and it is the one worth building.