From spaghetti prompts to structured plans: Tasklist in real-world engineering

AI Agents Are Powerful, But Can Be Messy

Most AI tools can write code. But when the work gets complex—multi-stage planning, multi-repo changes, long refactors—chat falls short.

You can’t see what the agent is doing. You can’t edit its plan. You’re stuck waiting and hoping it does the right thing.

Tasklist exists to fix that: it gives structure to agent work, and visibility to you.

What Is Tasklist?

“The way I view Tasklist is it’s a way for the agent to be communicating with me—and for me to kind of work with the agent in a way where we’re going back and forth on some surface that isn’t just a chat thread.” - Eric Hou, Engineer at Augment

Tasklist is a structured, editable surface that the agent reads from and writes to. Engineers use it to:

• Plan multi-step work before execution
• Supervise and intervene while the agent runs
• Make structural changes without restarting
• Reuse plans across similar tasks

“I’m typically starting off these large pieces of work by staging them using the Tasklist… I press play and kind of let the agent go do its work.”

Building Trust Through Structure

“Building trust is really just trying things… having a little bit of that willingness to try something you might not expect a computer to do well.”

Tasklist gives you a way to gradually increase trust: start with a scoped plan, let the agent run, monitor its progress, and step in when needed.

“It’s a lot like working with humans. You build trust by working with them—by taking a little bit of a step.”

And since the Tasklist is always visible and editable, there’s no need to read every message or log. You catch problems at the plan level, not the token level.

“If it updates the Tasklist with something I don’t think is right, it’s very easy to catch that and scan it at a high level rather than having to dig into all the details.”

Best Practices for Engineers Using Tasklist

1. Start with Exploration

When you're tackling a complex system change—like infrastructure updates, data model overhauls, or reviewing large pull requests—using Tasklist is an effective way to map out the work before diving into implementation.

“It’s really nice to get the agent to explore and create the Tasklist but not start implementing.”

This separates planning from execution. You can:

• Validate the structure before anything runs
• Add missing steps (e.g. tests, cleanup, rollout)
• Spot risky assumptions early

It’s a safer way to use the agent at scale.

2. Edit the Tasklist Mid-Run—Don’t Restart

If you’ve used tools where a bad plan means a full reset, Tasklist changes that. The agent reads live from the list. That means you can patch plans as you go.

“While it’s implementing the list, if I notice something I missed or want to change, I just update the Tasklist on the fly.”

No rerunning. No re-prompting. Just adjust and continue.

Use this when:

• The agent misses a dependency
• You need to reorder steps (e.g. migrate schema before modifying endpoints)
• You realize partway through that the scope needs to expand

3. Version and Reuse Tasklists Across the Codebase

Some workflows happen over and over again: adding feature flags, updating config files, publishing packages. You don’t need to reinvent the structure.

“I check in Tasklists. Like if I want to repeatedly add feature flags... I export it and check it in.”

You can:

• Store them in your repo (e.g. /playbooks/ or /tasklists/)
• Reference them with @tasklist-name inside prompts
• Let the agent adapt the structure to new inputs

This effectively gives you code-aware automation templates.

4. Let the Agent Learn from Its Own Plans

Agents can improve their own planning logic—if you ask.

“Anytime it does a Tasklist, ask it to update that Tasklist with what it would do next time.”

This works especially well for repeatable tasks like:

• Rolling out new endpoints across services
• Implementing similar auth changes in multiple places
• Testing CLI tools or SDK integrations

Prompt: “Reflect on this Tasklist and update it based on what worked and what didn’t.”

Over time, you build a smarter base plan.

5. Don’t Overengineer the Tasklist—Let the Agent Draft First

Most engineers aren’t writing Tasklists from scratch.

“It’s much easier to review something, look at a list and say, ‘this feels off,’ than to try to come up with the list in the first place.”

So don’t. Let the agent generate the initial structure, then treat it like code review:

• Trim redundant steps
• Clarify vague tasks
• Add your own internal tooling calls where needed

It’s faster, and avoids micromanaging.

Where Tasklist Fits — and Where It Doesn’t

As useful as Tasklist is, it’s not meant to cover every kind of interaction. When you're working with ill-defined problems or trying to quickly debug something in a one-off file, you don’t always need structured execution.

“If you're doing sensitive operations or things that require really fine-grained supervision... probably not the best fit.”

It’s also not ideal for simple Q&A or early-stage exploration where you haven’t yet defined what success looks like. But once the work has a clear shape—even a rough one—Tasklist gives you a stable interface to manage and scale that work reliably.

How Engineers Are Actually Using It

What’s been surprising: engineers aren’t the primary authors of Tasklists. Agents are. Most workflows now start by asking the agent to generate a plan. Engineers review, edit, and supervise from there. This is a shift in how work gets done. Engineers move from being executors to reviewers, from writers to directors. The plan is the interface.

Final Thoughts

“Tasklists are more important for the actual process of doing work.”

They give agents long-term memory, structure, and a shared state. And they give you a way to steer, adjust, and scale multi-step work without friction. Whether you’re rolling out a cross-service change, running multiple agents in parallel, or just trying to get repeatable workflows under control—Tasklist gives you the surface area to do it.