Pulse

The problem

Freelancers and consultants bill by the hour but log time badly. Timers and forms add friction at exactly the moment the work is happening, so hours go unrecorded — and revenue with them.

Pulse lets the work be logged in plain language, inside a chat app already open, and does the structuring afterward.

What is being tested

Whether plain language is a good enough interface for structured time tracking.

A message like "Spent 2h on the Acme website redesign yesterday" is turned by an agent into a typed entry — client, project, category, duration in minutes, a clean summary, the activity date, and a billable flag — with relative dates resolved. The whole agent output is a structured type, never free text; when the work is not a time log, it takes a separate chat path instead of forcing a bad parse.

The harder problem is knowing what the work belongs to, and Pulse leans on the data instead of guessing:

• rather than fuzzy string-matching, the agent calls a lookup tool that grounds parsing against the user's real clients and projects, which keeps it from spawning near-duplicate entities;
• it separates the billing entity ("for Acme") from the specific engagement ("Website Redesign"), two things a naive parser collapses;
• when something is genuinely ambiguous — an unrecognized client — it returns a clarification question ("create new, or link to an existing one?") rather than committing;
• it keeps message history, so "actually, that was for Google" fixes the prior turn.

"for Acme"          →  client   (who gets billed)
"Website Redesign"  →  project  (the specific engagement)

Technology

Built on the same webhook stack as the rest of the platform.

• Aiogram 3.x over FastAPI + Granian as the ASGI webhook runtime.
• Pydantic-AI with tool-use: the agent's output type is a Union of LogEntry | Clarification | chat, and it calls workspace-lookup tools mid-parse to ground entities against the user's real data.
• SQLAlchemy 2.0 + asyncpg over PostgreSQL with Alembic migrations for the client → project → entry schema, all strictly user-scoped; Redis backs the finite-state machine.
• Gemini (Google) as the environment-driven default model, with token-usage tracking on each agent run.
• Python 3.13.

What works today

• The full loop in commands: email-code login, natural-language logging with an interactive draft, report (Today / Week / Month), history, settings to manage clients, projects, and categories, and profile with stats and a full data-wipe.
• A relational model — client → project → entry, plus user-defined categories and report snapshots — with soft-delete via archive/restore and a complete deletion path.
• Tool-grounded entity resolution with create-new-or-link prompts, conversational onboarding (industry, then clients, then projects), multi-turn correction, and a reporting engine that rolls up Client → Project → Time over any range.

What I learned

What the build settled, ahead of any accuracy data:

• Tool-grounding beats string-matching. Letting the agent look up the user's real clients and projects mid-parse removed the duplicate-entity problem that fuzzy matching created.
• A Clarification return type is what makes free-text input safe to write to a database — the agent asks instead of inventing an entity.
• The client-vs-project distinction has to be stated explicitly in the prompt; left implicit, the model collapses billing entity and engagement into one.
• A structured Union output keeps an ordinary chat message from being force-fit into a time log.

Limitations and what's next

The roadmap items are the obvious commercial ones, none shipped yet: emailed PDF/HTML reports, billable rates and financial totals, and team or shared-workspace support. Registration can be gated to allow-listed Telegram IDs when run as a private beta.

And the maturity label is honest about itself: the internal "production-ready" tag is a self-assessment, not a measured outcome. There are no adoption numbers and no measure of extraction accuracy behind it yet — that is the next thing worth instrumenting.