Tiger Agent: a debugging checklist you could hand to a machine
We learned to debug before we learned to code properly. Not from a course, just from things breaking. Stare at the output. Change one thing. Stare again. Print statements showed up before abstractions did. Stack traces before design patterns. At some point we noticed the job was less about typing and more about following a trail.
The trail has not changed much:
- Read the message.
- Check the issue tracker, in case there is additional context.
- Find the place in the code raising the error and understand the conditions.
- Reproduce the issue, preferably with a script.
- Work through several fix plans and eliminate the ones that do not fit.
- Complete and review the best plan.
- Fix the issue according to the plan.
- Prepare a PR that explains both the issue and the fix.
Write it down and it stops looking like intuition. It looks like a procedure.
Our team has sketched Tiger Agent around that procedure: Sentry alert in, the same investigation steps we would run by hand, and provide either a fix PR or a heavy assist out the other side. It is still an idea. We prototyped it once, but we have not shipped it. This post is about the sketch and the prototype.
Adoption without a manual
LLMs are everywhere, and at work they often arrive as a mandate with no manual. Leadership wants adoption. Teams get little guidance on what to do with that on a Tuesday afternoon.
We already had the checklist above. That helped more than any generic āuse AIā slide. We know how we debug. The question was narrower: which steps on the trail could something else do?
Working that way surfaced useful patterns quickly. One of the simplest was keeping reusable context in separate markdown files instead of rewriting it for every conversation. It is decomposition and encapsulation, the usual engineering tools, applied to prompts.
The prompts started sounding like runbooks:
Hello, dear Agent. Our current inventory: {INVENTORY}. Hereās what we had before: {HISTORY}. You know what to do, go.
It is just maths with extra steps. We live in code, Jira, review comments, configuration files, and increasingly in instructions written for tools. Am I just doing this maths for a living? Maybe. I will now use a calculator.
Tiger Agent is that calculator: early steps only, wired to alerts, with explicit rules for when to stop and bother a human.
Early design
We are not inventing a new debugging philosophy. We want the checklist expressed as connections: webhook, tracker, read-only pass over the repo, then a human if things get weird.
Plumbing is mostly boring and mostly solved. Alerts carry context. Tickets exist. An agent CLI in Ask mode can already produce a āhere is the error, here is what I seeā report if you ask plainly. None of that needed a research programme. It only needed wiring.
Reproduction and picking a fix are the actual job. An agent that opens a confident PR on a flaky failure is actively harmful. So the design we care about is stop rules: open a PR when the evidence is there, post a summary and back off when it is not. After a patch, check the repro again, check the alert, then loop or quit. Not one-shot genius. Evidence.
First version, if we are honest: glue what already works, and be picky about what we pretend is solved.
Keeping focus
Debugging requires concentration, but much of the process is administrative. Open the alert. Find the ticket. Read the comments. Search the repository. Check the logs. Open another tab.
None of those steps are particularly difficult. The problem is that they interrupt the actual investigation. Every switch between tools risks losing the thread.
Tiger Agent is an attempt to remove some of that friction. Instead of spending attention gathering context, the developer starts with context already assembled. The goal is not to automate judgement. The goal is to preserve focus for the parts that require it.
Looking ahead
Reliable webhooks. Clearer stops. Learning where the stop rules should be once something runs long enough to teach us.
You do not need our full eight-step fantasy to try the same trick. Ingest the alert, pull tracker context, run a read-only report, and open a draft PR with what you found. That alone burns off tedium. Most pieces exist. The work is connecting them how you want, not inventing a new brain.
If you already have a debugging ritual, put it on paper. Count how many steps your stack covers today. We were surprised. You might be too.