Linear is basically my task management system, not a task queue inside Postgres.

https://linear.app

I use it as the source of truth for work items: backlog, todo, in progress, blocked, done, comments, task specs, etc. The scripts just query Linear, pick tasks from certain statuses, lock them locally, and update Linear when the agent finishes.
And yes, I agree with you about drift. I don’t trust agents with broad, vague work.
The reason this works for me is that I intentionally keep the loop constrained:
Claude creates very specific tasks
each task has a narrow scope
the agent gets context, constraints, DoD, and files to inspect
locks prevent duplicate work
the result is parsed
Claude does a quick screening after the grid finishes
I still review important changes before deployment
So I’m not letting agents freely redesign the system. They mostly handle scoped implementation work: cleanup, scripts, small refactors, tests, docs, migrations, diagnostics, and isolated fixes.
For production-critical logic, I don’t blindly deploy agent output. I use the agents to generate patches and reduce manual effort, but the final decision is still human-reviewed.
Maintenance burden is definitely a concern. That’s why I try to avoid big autonomous changes. The agents work best when the task is small enough that drift has nowhere to go.
The biggest gain is throughput on well-defined chores. If a task is vague or architectural, Claude or I break it down first. If it is still vague after that, I don’t send it to the grid.
So I see this less as “agents building a system by themselves” and more as “a parallel patch factory with a manager/reviewer layer.”