We built an AI inbox, then took it back out

For most of last year TIBLR had a feature called the AI Inbox. It connected to Slack, Gmail, and meeting transcripts, scanned them for anything that looked like a commitment, and proposed those as tasks with a confidence score. You reviewed the suggestions and accepted the good ones.

It is gone now, along with the Slack and Zoom connections that existed only to feed it. This is a note on why, because the reasoning generalises beyond us — and because we would rather explain it than quietly delete the marketing page and hope nobody noticed.

It demonstrated extremely well

We should be honest about the appeal, because it was not an obviously bad idea.

The problem it addressed is real. A significant fraction of the work a team commits to is created in passing — a sentence in a Slack thread, a line in an email, an offhand "I'll take that" in a call. It is genuinely a commitment and it is genuinely about to scroll out of view. Everyone has experienced the consequence.

And the technology worked. Extraction accuracy was decent, better than we expected. In a demo, watching a task appear that you recognised from a conversation two hours earlier was a small delight. People's reaction was consistently positive.

Then people used it for three weeks

The problem showed up in a pattern we noticed in usage data before anyone articulated it: the accept rate on suggestions was low, and — more tellingly — the number of unreviewed suggestions climbed steadily for most users.

We had built a queue. A queue of maybe-tasks, each requiring a human to read it, recall the original context, and decide whether it was real. It sat there accumulating, and it needed processing.

Which is to say: we had built a second inbox.

The entire premise of the product is that people have too many queues demanding attention and that the daily review should be short and finishable. We had added a new queue whose contents were, by construction, lower quality than the one people already had — because a human writing a task has already decided it is real, and a model proposing one has not.

Relocating work is not reducing it

This is the part we think generalises.

The feature did save the moment of writing a task down. That is a real saving, perhaps fifteen seconds. In exchange it created an ongoing triage obligation — reading suggestions, recalling context, judging, dismissing. Call it thirty seconds per suggestion, several suggestions a day.

The arithmetic never worked, and we did not do it before building. We had measured the thing we removed and not the thing we added, which in hindsight is an obvious way to fool yourself.

There is a broader version of this worth naming. A lot of AI features currently being shipped have this shape: the model produces a plausible artefact, and a human is now responsible for checking it. If checking is cheaper than producing, that is a genuine win. If checking requires reconstructing the context the model already had access to, it very often is not — and the feature has moved effort from a moment when the person had full context to a moment when they do not.

Extraction from conversations is squarely in the second category. Judging whether "I'll take a look at that" was a commitment or a politeness requires knowing the conversation, the relationship, and what happened afterwards. The model does not have that. The person did, two hours ago, and by the time they are triaging a queue they mostly do not any more.

What we removed with it

The Slack and Zoom connections existed to feed the AI Inbox, so they went too. Slack came back in a different, narrower form: you can turn a specific message into a task, deliberately, at the moment you decide it is one. Zoom did not come back, because without extraction there was nothing for it to do.

That narrower Slack feature is, we think, the correct version. The human makes the judgement while they still have the context, and the tool handles the mechanical part — creating the task, assigning it, keeping a link to the thread. No queue, no triage, no confidence scores to interpret.

It is far less impressive in a demo. It is considerably more useful on a Tuesday.

What we would need to see to try again

We are not ideologically opposed to bringing something like this back. We would want a version that clears a specific bar: it has to reduce total work, not relocate it.

Concretely, that probably means precision high enough that suggestions can be trusted without individual review, rather than recall high enough to catch everything. A system that surfaces two things a week and is right about both is more useful than one that surfaces twenty and is right about eight — even though the second one looks better in a demo and, we suspect, is what most teams building in this space are currently optimising for.

We are not there. When we are, we will say so.

The cost of saying this out loud

Removing a shipped feature is unpleasant in ways that are easy to underestimate. Some people liked it. It was the most distinctive thing on our marketing site. "We have AI" is currently doing a lot of work in this category, and choosing not to say it has an obvious cost.

We would still rather ship a smaller product that does not lie about what it saves you. If that reads as a marketing position rather than a genuine belief, the fairest test is what we do next — and whether, the next time something demos well and measures badly, we tell you about that too.

---

More on what we build and why in about TIBLR. The narrower Slack capture that replaced it is documented here.