Like every system there are bugs and change requests, this is no different for Soundtrak's AI Studio. However improving an AI system, which is simply a bunch of code, needs thought. It needs a backlog. So I gave the system a System Manager agent, its own session and its own queue of tickets, and even taught it to file tickets on itself. Here is where I started, where I ended, and what it taught me.
Where I started
For a long stretch I built the AI system and ran the campaigns in the same chat session. I would be halfway through producing a real asset when I noticed something wrong with the system itself. A rule that was missing. A review HTML page read badly to a human. Two agents interfered to create a poor output. An ongoing list of bugs and enhancements. So I would stop, address them there and then, mid campaign, a context nightmare even for an AI machine.
It felt efficient as I was improving the system exactly where the fault had shown itself, with the evidence sitting right in front of me. What I did not recognise initially is that the fix lived in the chat that produced it, and when the session closed it took the fix with it. Typically this would mean the fix wasn't complete, but a band-aid to the actual problem. I would encounter the problem again, band-aid it again.
The deeper problem was that the machine's memory and the campaign's memory were the same memory. Every session was doing two jobs at once, shipping the work and improving the thing that shipped the work, and the two were tangled in the same transcript. The human in the loop, me, was tangled in the transcript, so things weren't getting solved properly. Worse, when closing the campaign I threw away some of the lessons the system had just taught itself.
Campaign output was accruing, being saved to disk, it went under version control, it left a record. But the system changes didn't have a robust system of change. This meant the system only got better when I spent enough time to get it better, in the gaps between campaign deadlines.
I realised that in system design you need to build an engine that can be improved in a scalable manner.
Where I ended
Now the AI Studio has its own owner, its own session and its own queue of tickets, kept deliberately apart from any campaign.
There is a System Manager agent, a sibling to the Campaign Manager. The Campaign Manager orchestrates the work inside a campaign. The System Manager orchestrates improvement of the AI Studio that runs the campaigns. It holds its own backlog of enhancements, its own inbox for raw ideas, and its own backlog board.
It also has a self-ticketing loop. When the system identifies a rough edge mid-campaign build, such as operating surfaces not aligning, it does not stop the campaign to fix itself, and it does not lose the fault when the session ends. It raises a ticket, with the detail and the benefit in implementing it. The rough edge gets written up as an enhancement, dropped into the backlog, and left there for me to triage later, on purpose held apart from the campaign it interrupted. The campaign keeps moving.
As mentioned, I also built an operator surface where I can actually look at the backlog of tickets, the same way I review campaign assets on a gallery rather than by scrolling a transcript.
The System Manager dashboard, the operator surface for improving the system itself. The backlog splits into what needs my decision and what the system can action on its own, each ticket with its benefit and a priority. This is where the self-ticketing loop drops the faults it finds, held apart from the campaigns.
So the two jobs are separated. The campaign ships in its own session and files against its own record. The system improves in its own session, against its own backlog. When I want to make the machine better, I open the System Manager and work the ticket queue, or add my own tickets. And because the system files its own tickets, flagging its own faults as it runs, by the time I sit down to triage all I am left with is the part that actually needs me: deciding what to fix, and in what order.
What it taught me
When building a system, you have to expect to enhance it. It is ok to build the airplane whilst flying it, but enhancements need their own process and workflow.
Recognising that a session memory can get confused, and loses its store over time, meant that you could not rely on it entirely. Stopping mid session and asking the system to capture the fix, or the enhancement in its entirety and then publishing it to a backlog, a store of information, solved this. It also meant that the flow of the campaign wasn't broken trying to fix something immediately.
Supporting this with its own agent, HTML 'human-in-the-loop' operator surfaces, eval files and tools became the system for enhancements.
Part two of the lesson is that it is not enough to give improvement a home. You have to let the system notice its own faults and queue them itself, because the alternative is a machine that only improves as far as the operator remembers to improve it. We built a weekly scheduled task for the system to do this. A system that files tickets on itself improves by design.
Part three of the lesson is to include the human in system improvement. We handed the human a queue to review, choosing which ones to fix and in what order. The decision to improve isn't for the machine to make, the machine just makes it much easier to do.
If you are wiring AI into your own go-to-market, build a system improvement workflow, so it improves whether or not anyone was paying attention.
The evidence
- Started: System fixes made mid-campaign, in the same chat as the work, lost when the session closed.
- Ended: A dedicated System Manager with its own session, backlog and HTML surface, plus a self-ticketing loop that captures faults weekly.
- Changed: Improvement got its own owner, surface and queue, held apart from the campaign it interrupts.
- Learned: Separate the machine's memory from the work's memory; run improvement on its own clock, not in the gaps between deadlines.
- Learned #2: Let the system file tickets on its own faults. It improves by design, not by whoever happens to remember.
- Dated: 2026-06.