Why chat and traditional tickets aren't enough when you work with AI agents
You asked your agent to “add pagination to the user list”. It came back with the pagination done… and, along the way, changed the response format of two endpoints that already worked, because “it felt more consistent”. Nobody asked for that. Nobody forbade it either.
If you work with Cursor, Claude, Aider or Windsurf on a real project, that scene is familiar. And the easy takeaway —“the agent got it wrong”— is the wrong one. The agent did the only thing it could with what it had: fill in the gaps. The problem wasn’t the agent. It was that there was no source of truth telling it what was in scope and what wasn’t.
In the first article we talked about why agents fail when tasks aren’t clear. Here we go one step further: even if you have tasks, if they live in the wrong place —an endless chat or an ambiguous ticket— the agent is still working blind.
How we manage projects today, with agents in the mix
Before agents, most people’s “system” was a reasonable blend: some conversation (Slack, the editor chat), some tickets (Linear, GitHub Issues, Plane, Height) and a lot of human memory. It worked because the glue was you. You remembered why that decision was made, you knew that ticket actually depended on another one, you translated “just fix it” into five concrete steps.
The moment you add an agent, that glue disappears. The agent wasn’t on yesterday’s call. It didn’t read the thread where you decided not to touch the payments module. It doesn’t know that “the login bug” has already been discussed three times. You hand it a sentence and an editor with access to the code, and expect it to behave like a teammate with six months of context. It has none.
And here’s the uncomfortable part: the agent works far faster than you can review. It can touch fifteen files in the time it takes you to read one diff. So any gap in context doesn’t produce a small, contained error: it produces broad, fast, misaligned work that you then have to undo.
Why chat isn’t enough
Chat is great for thinking out loud. It’s terrible for governing a project. With an agent in the loop, that difference stops being a detail and becomes the problem.
Context dilutes
A conversation is linear and ephemeral. What you said twenty messages ago is no longer “active”: it’s buried. Agents, on the other hand, need stable context, not fluid conversations. A chat thread is the opposite of stable: every new message pushes the previous one toward oblivion, and the model’s context window has a limit. You paste in half the thread, the agent keeps half of that half, and it fills in the rest on its own.
Important decisions get buried
Think about the real decisions in a project: “we use UUIDs, not auto-increment IDs”, “emails are sent fire-and-forget”, “we don’t touch the public API without versioning”. Those decisions almost never live in a stable place. They live in a stray message, in a PR comment, in the head of whoever made them. In a chat, a critical decision and a “has anyone had lunch?” carry exactly the same visual weight and the same life expectancy.
When the agent needs that decision, it can’t find it —because it isn’t anywhere it can query— so it decides on its own. And sometimes it decides differently each time.
No state, just messages
A chat has no state. You can’t ask it “what’s in progress?”, “what got blocked?”, “has this been done already?”. You can only scroll. For a person that’s annoying; for an agent it’s useless: there’s no way for a model to “remember” the project state by reading a river of messages. Agents can’t remember the project state if there’s no source that represents it.
Why traditional tickets aren’t enough either
“Fine —you’ll say— that’s what task trackers are for.” And yes: Linear, GitHub Issues, Plane or Height are a huge leap over chat. They have state, assignment, history. But they were designed for a world where the reader of the ticket is a person. And a person fills the gaps with judgment; an agent fills them with statistics.
The ticket assumes a human reader
A title like “Improve dashboard performance” is perfectly actionable… for someone who’s been on the project for months. They know which dashboard, what “slow” means, what’s acceptable and what not to touch. The agent knows none of that. It sees six words and a half-empty description box. The ambiguity a human resolves with context, the agent resolves by inventing.
There’s no structure an agent can follow
Traditional tickets capture the “what” well and almost nothing else: what’s already done, what depends on what, what’s out of scope, how the result is validated, which decisions apply. That information —when it exists— is scattered across the description, the comments, the labels and three linked PRs. It’s scattered information, not a source of truth. For you, reconstructing it takes a while. For an agent, which can’t “wander around the project” or ask down the hall, it’s simply inaccessible.
They still depend on you
The practical upshot is that the classic task tracker doesn’t remove your translation work: it hides it. You still have to sit in the middle, explaining in chat what the ticket doesn’t say, recalling the decision that was never written down, flagging the dependency nobody modeled. The agent isn’t working against the project: it’s working against your availability.
The real cost of this gap
This distance between “how we store the information” and “what an agent needs” isn’t theoretical. It gets paid, and it gets paid in very concrete places:
- Time doesn’t drop. They promised to speed you up, and you end up spending the time you saved re-explaining the same context every session, from scratch.
- Agents that improvise. With no clear boundaries, the agent “improves” things nobody wanted touched, duplicates logic that already existed, or solves the wrong problem with great confidence.
- Silent rework. The change looks right, passes a quick review, and two days later you find it broke an assumption that lived in someone else’s head.
- Zero traceability. When something goes wrong, there’s no way to reconstruct why the agent did what it did. The decision wasn’t recorded, the context wasn’t linked, the state wasn’t reflected. All that’s left is the diff.
None of these costs come from the model being bad. They come from asking an agent to operate without a source of truth, and then being surprised when it invents one.
The key idea: tasks and epics as the single source of truth
Here’s the reframe. If you want an agent to work well, the project needs one place where the truth lives: what needs doing, what state it’s in, what depends on what, what was decided and what’s out of scope. Not spread across a chat, three tickets and your memory. One.
The natural unit of that source of truth isn’t the message or the loose document: it’s the task, grouped into epics, inside projects. A well-formed task isn’t a title; it’s a small, stable contract: the goal, the scope, what’s out of scope, the dependencies and how it’s validated. An epic gives the big picture: what you’re building and how the pieces fit.
The difference between scattered information and a source of truth is exactly that. It’s not how much information you have, it’s whether there’s one queryable, structured and stable place both you and the agent can turn to and get the same answer. A chat has plenty of information and no truth. A source of truth has less noise and one clear answer.
What changes when the agent has real structure
When the agent can read that structure instead of guessing it, the work changes in character:
- It stops filling gaps. It works on a concrete unit with a defined scope, so it doesn’t “improve” what it shouldn’t touch.
- It decides consistently. The project’s decisions are written down and queryable, not reinvented every session.
- State is real. “Done”, “in progress” and “blocked” mean something, and both you and the agent can trust them without doing archaeology in a thread.
- There’s a trail. Everything has its place, so when something goes sideways you can reconstruct the what and the why.
- You stop being the glue. Context no longer depends on you being available to explain it: it lives in the project.
Notice what we did not say: nothing about “the agent becomes autonomous and you stop reviewing”. Quite the opposite. A source of truth doesn’t remove human control; it makes it cheap. Reviewing against a written scope is fast. Reviewing against “what I had in my head” is exhausting.
Where Hilbana comes in
Hilbana grows out of exactly this idea: making tasks, epics and projects the source of truth your agents can follow without getting lost. Not a chat that dilutes, not a ticket that assumes a human reader with six months of context. A structure designed from the start so people and agents read the same thing, under the same rules.
We’re not going to break down how it does that piece by piece today —that’s for the next articles—. Today’s positioning is simpler and, we think, more important: the bottleneck when you work with agents isn’t the model, it’s the substrate you ask it to work on. And that substrate, today, is still a chat that forgets or a task tracker that only speaks the language of humans.
If your project had a real source of truth —stable, structured, queryable by a person and by an agent— half the problems we’ve talked about would stop happening. That’s the gap Hilbana wants to fill.
Want to start working this way with your agents?
Create a free account and try Hilbana with an agent-ready project.
→ Create your workspace for free
Or, if you’d rather understand how it works first: