Hermes Task
- Aug 2026
- Timeline
- Design Engineer
- Role
- Solo
- Team

Overview
How do you remember everyone you met, and what you promised each of them?
The Incipe team is four people, and between us we meet investors, partner institutions and distributors every week. Hermes Task tracks those people and the tasks we owe them. Nobody has to open it to keep it current: you tell Hermes, an open-source AI agent, in Telegram, and it updates the app. I designed and built it on my own in eleven days.
Problem
After LEAP East, I had more people to follow up than I could remember.
A week at a conference ends with a pile of contacts and a promise made to each one. The tools we had stored tasks, but they forgot who each task was for. And at the end of a day of meetings, nobody wants to open another app.
People pile up
Investors, institutions and distributors arrive faster than anyone can remember them.
Promises slip
Each conversation ends with something we owe them, and that is the first thing to go.
Apps wait to be opened
After a day of meetings, a dashboard is one screen too many. A message is not.
Approach
Tell an assistant instead of filling in a database.
When you get home from a meeting, you could open an app, find the person and fill in three forms. Or you could send one message. So we had to ask: what if updating the app was as easy as telling a private assistant what happened?
A task app 5 steps
- Open the app
- Find the person
- Write the meeting note
- Create each task
- Set the next follow-up date
Hermes Task 1 step
- Send Hermes one message
Follow up on time
Both end with the same record.
Hermes reads "I met Williams today, I'll meet him next Monday, help me prepare a proposal". From that one sentence it writes a meeting note on David Williams, creates two tasks with due dates and sets when to get back to him. The app on screen changes while you watch.
Agent
Everything is designed so Hermes reads as little as possible.
Every time the agent reads or writes, it spends tokens and time. So I judged every change by one question: does this cut what Hermes has to read for each message?
Short IDs
Every record gets an ID like T-20 or C-6, never a 36-character UUID, so you and Hermes call it by the same name.
Three verbs
Hermes can apply changes, find a record or fetch the daily brief. One message becomes one batch of changes.
Replies to repeat
The server answers with a single line per change, written so Hermes can pass it straight on to you.
When a name matches two people, Hermes asks which one you mean instead of guessing. A mistake is fixed the same way it was made: change it in the app, or tell Hermes to put it back. The app has no chat panel of its own. Telegram is the only place to talk to Hermes, so every change, from a person or an agent, goes through one write path and lands in one timeline.
Reminders
The assistant comes to you.
Each person has a date for when to get back to them, and the app has no scheduler of its own. Hermes runs a scheduled job instead: it fetches the day's brief, which is already written out, and sends it on. It lists what is due, what is waiting on someone else and who needs a follow-up today.
Other agents can connect too. Each member creates their own access key in the app and gets an MCP server that holds no database password, so it is safe to hand to a colleague.
Speed
Clicking a tab asks the database for nothing.
The first version was as slow as ClickUp. One hour of one person browsing made 1,692 database requests, for nine contacts and five tasks. I took the idea behind Linear's sync engine and built the small version of it:
- One copy in the browser. The server sends the whole workspace once, on a cold load. Every screen reads from that copy, so going from Tasks to Connections and back costs zero requests.
- Saved for the next visit. The copy is also saved in the browser and read before the first paint, so a return visit opens on yesterday's data and quietly catches up.
- Live without polling. When someone else, or Hermes, changes something, the database pushes a signal and the copy refreshes. No refresh button.
- Edits show first. Your change appears at once and is saved behind it. If the save fails, the old value comes back.
- No loading screens. I deleted every skeleton. If something still flashes, that is a bug, not a wait.
- 1,692
- requests in one hour, before
- About 30
- requests in two hours on an iPhone, after
- 0
- requests to switch tabs
Motion
The page can slide because it never waits.
Pages slide in the direction you are going, so you always know whether you went forward or back. The old page stays put while it leaves, so the two pass each other instead of one cutting to the other. The slide only works because the new page has nothing to wait for. Otherwise it would be a moment of empty box sliding in.
Animate route changes as a short directional slide:
- 250ms: 8px of travel, a fade and a 3px blur.
- Slide forward or back according to where the user is going.
- Keep the old page mounted while it leaves, so the two pages cross rather than cut.
- Only do this when the next page renders from local data with no fetch; otherwise the slide is 250ms of empty box.
Trade-off
I left out the parts Linear only needs at scale.
Linear also keeps a full local database, tracks every field on its own and sends only what changed. Those pay off at tens of thousands of rows. This workspace holds tens. So any change re-reads the whole workspace, and the copy lives in plain browser storage, which can be read before the first paint.
Reflection
What I would keep.
Design for the agent
When an agent is the main user, its token budget is the interface.
Meet people where they talk
A message gets sent; a form gets put off.
Delete the wait
Fast is not a faster spinner. It is no reason to show one.
Built with
Next.js, Supabase and Hermes.
Next.js and Supabase, with Supabase Realtime for live updates, the open-source Hermes agent in Telegram, and an MCP server so other agents can use the app too.
















































