A Worker Should Know What It's Working Toward

The old button was called Work Linear tickets.

That name sounded fine right up until we looked at what it actually meant.

If you clicked it on an objective in AGX, it did not really “work on the objective.” It created a scheduled task, pointed it at Linear, let it look at a list of tickets, and asked it to choose one. If there was a ticket it liked, it worked the ticket. If there wasn’t, it stopped. That was the whole worldview.

At first glance, that feels close enough. Objectives usually have tickets. Tickets usually need work. Ship it.

But after living with it for a bit, the gap became obvious: we had built a ticket picker and were pretending it was a worker.

That distinction matters more than it sounds.

The fake autonomy problem

The problem with the old setup was not that it was broken. The problem was that it looked smarter than it was.

An actual objective worker should know what the objective is. It should know what “progress” means. It should know whether there’s recent activity, whether someone is already working a ticket, whether there are notes explaining constraints, and whether the right move is to create a plan instead of touching Linear at all.

The old version knew almost none of that.

The Linear ticket for the redesign was blunt about it. The controller only saw Linear tickets. Tickets were privileged. The objective’s cadence field existed, but didn’t mean much unless you manually created another scheduled task. The worker had no real awareness of notes, activities, active sessions, or project context. Most importantly, it had no real concept of the objective’s goal.

That’s the bug.

When a system only knows how to choose from a queue, it will keep trying to prove its usefulness by choosing from the queue. Even when the right answer is “read the note first,” “summarize what happened yesterday,” “draft the missing plan,” or just “stop, because somebody else is already on this.”

That is not a worker. That is a menu with side effects.

We rebuilt the loop around the goal

This week the objective worker got redesigned around a much stricter model: observe, decide, act, receipt.

That sounds like architecture-language, but the practical change is simple. Every objective now gets a built-in worker job, and each run is supposed to look at the objective through the lens of the objective’s goal before it does anything irreversible.

The decision contract is small on purpose:

type ObjectiveAction =
  | { action: "work_ticket"; ticketId: string; reason: string }
  | { action: "run_prompt"; prompt: string; reason: string }
  | { action: "stop"; reason: string };

That middle option is the important one.

The old system mostly assumed the world should already be represented as a ticket. The new system admits that sometimes the most useful next move is work that hasn’t been ticketed yet. Read the notes. Refine the plan. Write down the missing next steps. Review the recent activity and figure out why progress stalled. Ticket work is still there, but it’s no longer the only thing the worker is allowed to imagine.

And stop is just as important.

One of the easiest ways to make an automation system noisy is to treat inactivity as failure. It isn’t. Sometimes the correct decision is that no action adds value right now. A real worker needs the ability to say that out loud.

The worker now sees more than the queue

The code change that makes this feel real is not the JSON type. It’s the observation phase.

The new buildObjectiveObservation(...) path gathers the goal, current status, notes, recent activity, objective-linked Linear tickets, active sessions, sibling objectives, and scheduled tasks before the controller decides what to do. In other words, the worker now starts from the same kind of situational context that a decent engineer would want before taking over someone else’s project.

That changes the texture of the system.

Before, “autonomous objective work” mostly meant “I hope the ticket list is a good enough proxy for the objective.” Now it means the worker can actually ask a more grounded question: what single action most advances this objective right now?

Sometimes the answer will still be a ticket. Good. Tickets are useful.

But sometimes the answer is a prompt. Sometimes it is a planning pass. Sometimes it is to stay out of the way because another session already has the relevant issue open. Those are the behaviors that make a worker feel like it understands the assignment instead of just recognizing the nearest to-do item.

Then we generalized the pattern

The interesting follow-up landed almost immediately.

After redesigning the objective worker, AGX added a scheduled Linear worker that uses the same basic idea in a different scope. The objective worker is goal-scoped. The Linear worker is workspace-scoped. Instead of being attached to one objective, it watches the whole Linear workspace and prioritizes work using a user-defined prompt.

That is a much better abstraction than hiding everything behind a generic scheduled-task editor.

The configuration lives where you’d expect it: in the Linear interface. Under the hood it still uses the scheduled-task system, but the product surface now matches the mental model. You set the prompt, cadence, team, and script behavior in the place where you’re already thinking about tickets and work selection.

The default guidance is also telling. It does not say “go do more work.” It says: prefer tickets already in progress, prefer assigned or unassigned tickets, skip ones with active-session, use an isolated worktree, keep Linear accurate, and leave the session in a resumable state.

That is the design lesson showing up again: autonomy is not “do whatever seems productive.” Autonomy is “operate inside a narrow contract that preserves context for the next run.”

This is really a product honesty story

What I like about this round of changes is that it made the product more honest.

If a feature is basically a queue picker, call it a queue picker. If it is a worker, it should actually know the goal, the current state, and the other things happening around it.

There is a tendency in agent products to over-credit thin abstractions. A thing creates a ticket, opens a PR, or posts a comment, so we start describing it as if it has a robust model of the work. Sometimes it does. Often it doesn’t. Often it is just one prompt standing on top of a very flattering UI.

This week felt different because the redesign did not add more hand-wavy capability. It removed a fake layer of intelligence and replaced it with a smaller, clearer contract.

That’s almost always the better trade.

The system is allowed to work a ticket.

The system is allowed to do preparatory work that is not already ticket-shaped.

The system is allowed to stop.

And in order to choose among those, the system has to look at the surrounding context instead of just the queue.

That is what makes the behavior more believable.

What this changes from the outside

If you use AGX day to day, the immediate effect is that objective automation should feel less twitchy and less ceremonial.

You are no longer clicking a button that secretly creates another little ticket-dispatch robot and hoping it approximates strategic work. You are triggering a built-in worker that already belongs to the objective. That worker can inspect notes, receipts, active sessions, and ticket state before it decides what to do.

And if you’re working from the Linear side, the new scheduled Linear worker gives you a project-wide version of the same idea. Not “run a generic scheduled task against tickets,” but “set the rules for how this workspace should decide what matters next.”

That is a much more useful primitive.

Because the real promise of agent software is not that it can always act. It’s that it can tell the difference between when it should act, when it should prepare, and when it should leave the keyboard alone.

We are still early on that curve. But this week felt like a real step toward it.

The biggest compliment I can pay the new design is that it sounds less magical than the old one.

It sounds more like work.

That is why I trust it more.