You can connect AI to your task list now. Todoist has MCP. Notion has an API. ChatGPT has memory and a tasks feature. The AI reads your list and narrates it back to you in a sentence instead of a table.
That's not the problem I was trying to solve.
I spent years cycling through productivity tools and the past year experimenting with AI on top of them. Same wall every time. The AI could see my tasks but it couldn't tell me anything I didn't already know. It couldn't say "this project is quietly falling behind" or "you should start this now, because tasks like this take you about three days." It couldn't tell me I miss a third of my Thursday deadlines or that I've been completing less work each week for the past month.
It can't. That information doesn't exist in a task list. Nobody is computing it.
So I built something.
What I built
Tycana is an AI productivity assistant. You open a chat and talk about your work. Everything persists across sessions. But the difference isn't memory — it's that the backend computes things from your data that a language model can't compute on its own.
How long things actually take you, measured from your completion history. How often you finish things on time, and whether you need more buffer. Which tasks are quietly going stale versus which ones are just scheduled for later. Whether you're trending up or down over weeks.
When the AI says "medium-effort items take you about three days," that's computed from your history. When it says "the client proposal has been sitting untouched and it's due Friday," that's persistent memory plus stale detection. The intelligence comes from the system, not from the language model improvising.
Day 1 vs. day 30
This is the part that matters most to me, and it's the hardest to explain without experiencing it.
Day 1, Tycana captures tasks and helps you plan your day. You tell it what you're working on, it remembers, you can ask for a status check. Useful immediately, no setup required.
By week 2, early patterns start forming. The system has enough data to notice your pace, flag things that are falling behind.
By week 4, it knows you. It calibrates estimates based on how long things actually take you. It spots work that's stalling before you notice. It gives advice informed by your specific history, not generic productivity wisdom.
Most productivity tools have the same value on day one as they do on day three hundred. More tasks, same experience. The tool doesn't know you any better after a year than it did after an hour.
The behavioral data in Tycana accumulates. The signals get more accurate as sample sizes grow. A new product can copy the feature list. It cannot copy months of your behavioral history.
Between sessions
The conversation is the main surface, but there's more going on between sessions.
A morning briefing arrives in your inbox before you start your day. What's on your plate, what carried over, what needs attention. A weekly review lands on Friday: what you finished, what slipped, patterns worth noticing. Your tasks show up in your calendar feed alongside your meetings. You can forward an email to Tycana and it extracts the task automatically.
The right productivity system is one you don't have to remember to open.
If you already use Claude, Cursor, or another MCP-compatible AI client, you can connect them to Tycana's backend directly. Same intelligence, same tools, through the AI you already use. Most people will use the native chat at app.tycana.ai. MCP is there for people who prefer their own setup.
Early days
This is where I should be straightforward about the product's stage.
Tycana is live. You can sign up, use it, and pay for it. The intelligence layer computes real signals from real data. The architecture works.
But it's early. I'm a solo founder. The product is weeks old, not years. There are no growth graphs to share, no testimonials, no case studies.
The intelligence signals need your data to become meaningful. Your first day is useful for capture, planning, and status checks. The "gets smarter over time" part takes time. Effort calibration needs a few weeks of completed tasks. Slip rate tracking needs enough deadlined items to be statistically meaningful. That's why the trial is 30 days, not 14.
The compounding thesis is architecturally proven but commercially unproven. I've built the system that computes behavioral intelligence from structured task data. I have not yet proven that enough people will use it long enough to experience that intelligence becoming something they'd miss if it were gone.
This is a bet. I think it's a good one. But I'm not going to dress it up as a sure thing.
If that resonates, try it. Thirty days free. No credit card.
The full product story is at tycana.ai/why.
Top comments (5)
this hits a real nerve. the "memory" most AI tools offer is basically key-value storage -- it remembers your name and preferences but not the shape of your work over time. what you're describing is closer to derived state: computed insights from historical patterns that the raw task list never surfaces. the re-explaining problem is really a context compression problem. every new session starts from zero because there's no efficient way to carry forward what mattered from the last 50 sessions without blowing up the token budget. curious how you're handling that tradeoff between context richness and inference cost.
The approach I took has two layers. First, the backend computes signals from your history (velocity, slip rates, effort calibration, stale detection) and the LLM gets compact computed output at query time. So instead of stuffing a token window with months of conversation transcripts, the model receives something like "medium-effort tasks take this user about 3 days, their slip rate on deadlines is 38%, these two items have been untouched for 12 days."
Second, those same signals act as retrieval pointers. They tell the LLM where to look deeper. The backend lights the path, the LLM does the reasoning. So if the slip rate on a project is climbing, the model knows to pull that project's recent history and figure out why, rather than carrying all of it in context by default.
This sidesteps the context compression problem because you're not stuffing the window. You're giving the model structured intelligence plus breadcrumbs to pull more when it needs to think something through. Inference cost stays roughly flat regardless of how long someone has been using it. The expensive compute shifts to the backend, where it's math over structured data, not token processing.
the retrieval pointer idea is smart. keeping inference cost flat by pre-computing signals on the backend is way more scalable than throwing everything into the context window and hoping the model figures it out. the tricky part i've hit is calibrating how aggressively to compress -- too much and the model loses nuance, too little and you're back to the token bill problem. curious how you handle edge cases where the computed signals miss something the raw history would've caught****
What helped most was building a test harness — feed the same queries against different compression levels, compare the outputs. Then tune and iterate.
that's the right approach imo. the tricky part is defining what "same output" means when you're comparing compressed vs uncompressed — exact match is too strict, semantic similarity scores can be misleading. we ended up using task-specific evals (did the agent still complete the workflow correctly) rather than output-level difng**