Inspiration

My work rarely arrived as a clean list of tasks. Action items were scattered across email, Slack conversations, and meeting notes, so figuring out what I needed to do meant checking several places and rebuilding the context each time.

I wanted to bring that material into an LLM, turn the relevant action items into durable tasks, and then keep working from the same LLM interface wherever I happened to be. But context was always the weak point. A new conversation could lose track of what had already been captured, and I did not want the assistant repeatedly pulling or recreating the same tasks.

My company uses Jira, but not every small follow-up or personal action item belongs in the company system of record. Trello and traditional task managers can hold the tasks, but they were designed around people opening another app—not around an LLM reliably reading, updating, and collaborating through a structured interface.

I wanted an independent task layer purpose-built for LLMs: durable enough to preserve context across conversations, accessible from anywhere, and separate from whichever project-management system a company happens to use. That became canh—the to-do list you never open.

What it does

canh is a hosted, multi-user task and project layer exposed through the Model Context Protocol (MCP). An assistant can create, find, update, assign, organize, and discuss work on a user's behalf, while canh provides durable storage, permissions, history, and collaboration.

The user's LLM can extract action items from sources such as email, Slack, and meeting notes, then record them once in canh. Idempotent ingestion and persistent history help prevent the same work from being recreated whenever the conversation or model changes. Later, the user can retrieve the tasks—with their status and context—from any compatible LLM client and continue working where they left off.

People can use canh individually or with teams and organizations. The system supports boards, tasks, due dates, recurrence, templates, comments, task relationships, assignment, cross-team moves, event history, recoverable deletion, and protected batch operations. A web control surface handles sign-in, teams, credentials, and account management.

canh is deliberately model-agnostic. It runs no LLM itself and stores no credentials for source systems. The user's chosen assistant does the reasoning and calls canh over MCP, so the same task layer can work with Codex/ChatGPT, Claude, Grok, Gemini Enterprise, or another compatible client.

How I built it

The backend uses Python 3.12, Starlette, FastMCP, async SQLAlchemy, PostgreSQL 18, and Alembic. It is deployed on Google Cloud Run and Cloud SQL. Authentication and the web control surface use Firebase, and infrastructure is managed with Terraform.

I designed the system around strict tenant isolation, scoped credentials, idempotent writes, explicit actor attribution, and optimistic concurrency. Those choices matter because an AI agent may retry actions, act for a delegated user, or operate concurrently with a human teammate.

After I finished creating the basic functionalities of task management, I had the AI come up with many scenarios of how users would prompt their AI to get tasks done. I spawned many AI agents to act out as testers for those scenarios and give me feedback. Their feedback was fed back into a whole software development lifecycle where coding agents would take the feedback and plan to implement features to help fix the AI user's/tester's use case. After dev work was completed the test cycle with the scenarios was started anew and the AI agents testers gave new feedback. This went only for at least 4 cycles where. ChatGPT Sol with codex was used to ship those features.

What changed during OpenAI Build Week

canh is a pre-existing project. I began it in June 2026 and initially developed it primarily with Claude; the core hosted MCP task store, authentication, persistence, and web surface existed before Build Week.

Starting July 17, I used Codex with GPT-5.6 to audit, test, harden, and meaningfully extend the product. The new work includes:

  • agent-agnostic repository and product guidance;
  • richer event history, comments, recoverable deletion, conditional writes, query packs, recurrence, templates, relations, assignment, and cross-team moves;
  • expanded team and organization collaboration, guest behavior, credential scoping, delegated-actor attribution, lifecycle controls, and tenant-isolation tests;
  • immutable batch identity, preview/apply batch undo with compare-and-swap protection, and recurrence-occurrence history; and
  • repeated implementation review, verified concurrency and authorization fixes, and full CI-equivalent validation before integration.

The dated commit and pull-request history in the private repository separates the earlier work from the Build Week additions. A representative Codex/GPT-5.6 thread is session 019f8556-a7b3-7da3-abd8-6b44db74ccf9. It delivered batch undo and occurrence history through PR #264 and finished with 648 Python tests, 22 JavaScript tests, and 92.83% aggregate coverage.

Challenges

The hardest part was preserving predictable behavior across humans and agents. Batch undo, recurring-task history, cross-tenant authorization, retries, and concurrent updates all require stronger guarantees than a typical demo CRUD app. I also wanted a model-agnostic architecture: canh must provide useful structure to an agent without hiding business logic inside model prompts.

Accomplishments

I am proud that canh is a live, end-to-end SaaS foundation rather than a single-client prototype. It has a production MCP endpoint, a web management surface, multi-tenant collaboration, a comprehensive automated test suite, and an architecture that lets users keep their choice of assistant.

What's next

Next I want to streamline onboarding, publish supported connector listings, improve the human web experience, add production billing and operational tooling, and continue turning canh into a sustainable SaaS product.

Built With

Share this project:

Updates