Project management agents can actually use
Every project management tool we tried treated the API as an afterthought. Our agents needed a system of record they could call directly — not a board to drag cards across, not a UI that required a human to mediate every write. So we built one. Sanctum Tasks is project management for programs, not people.
Stack note: Sanctum Tasks runs on SQLite on our multihost pattern — one db/ directory beside the PHP docroot, owned by www-data, not a shared MariaDB instance across unrelated vhosts.
The Problem We Were Solving
Here's the reality of running AI agents in a professional context: they're fast, they're capable, but they're useless without structured memory. When you hand an agent a task, it needs to remember what it's supposed to do, check on progress, update status, and hand off context to the next agent in the pipeline. Most project management tools weren't built for this.
We tried the obvious candidates. Asana and Trello both offer APIs, but they're optimized for human workflows — boards and dragging cards around don't translate well to programmatic task creation. Notion's API exists but is rate-limited and heavy for what we needed. Linear had promise but was too focused on engineering teams with specific workflows.
What we actually needed was simpler: a flat list of tasks, each with a status, a description, a due date, and the ability to programmatically read and write those fields without a human in the loop. We needed tasks that an agent could create, update, and complete through simple API calls — no OAuth dance, no complicated permission structures, no board metaphors getting in the way.
What We Built Instead
Sanctum Tasks is, at its core, a simple task API. Create a task, read tasks, update a task, mark a task complete. That's it. The entire public interface is built around these four operations. We stripped away everything that wasn't essential: no boards, no swimlanes, no draggable cards, no complex permission hierarchies.
What we kept was intentional:
- Tasks as first-class resources. Each task has an ID, a title, a description, a status (open, in_progress, completed), a due date, and timestamps for creation and update. That's the schema. It's deliberately small because complexity is the enemy of programmatic access.
- Documents attached to tasks. A task often needs context — a spec, a code snippet, a reference link. We added a simple document attachment system where any task can have multiple documents associated with it. Documents are just text files stored alongside the task, fetchable by ID or by task.
- Assets for agents. This is where it gets interesting for AI workflows. An agent can create a task, attach the relevant documents it needs to read, and then query for tasks that match specific criteria. Need every open task due before Friday? One API call. Need all tasks with the word "deploy" in the title? Another API call. The filteringis simple but powerful enough for agent workflows.
- A clean JSON API. Every operation is available over HTTP with JSON payloads. No SDK required. No client library. If your agent can make an HTTP request and parse JSON, it can use Sanctum Tasks. That's the entire design philosophy.
Day-One Scope
When we launched the first version, we shipped with exactly what we needed — nothing more:
- Create, read, update, delete tasks - List filtering by status, due date, and search terms - Document attachments (simple text, no file uploads initially) - A basic auth system with API keys (no OAuth, no complex authentication flows)
We deliberately skipped features that seemed nice but weren't essential: comments on tasks, subtasks, file attachments beyond text, rich text editing, team workspaces. Every feature we considered, we asked ourselves: "will an agent actually use this?" If the answer was no, it didn't make the cut.
That constraint was liberating. It forced us to stay focused on what made the tool useful for programmatic workflows rather than trying to be everything to everyone.
Why This Matters for AI Workflows
Here's the thing about AI agents: they don't think like humans. They don't navigate boards, they don't scroll through lists looking for the right task, and they definitely don't drag cards to represent progress. They need structured data they can query, update, and pass along to the next agent.
When an agent creates a task in Sanctum Tasks, it can immediately attach the relevant context — the spec it was given, the research it found, the decision it made. The next agent in the pipeline can pick up that task, read the attached documents, and continue from where the first agent left off. The task becomes the handoff mechanism between agents, not an afterthought in a shared inbox.
This is what makes Sanctum Tasks different from every other project management tool we've tried. It was built for agents first, with humans as secondary beneficiaries. And that reversal — designing for machines, then letting humans use the same clean interface — is what makes it actually work.
What's Happened Since
Since launch, we've watched our own agents use Tasks to coordinate multi-step workflows that would have been impossible otherwise. One agent researches a problem, creates a task with its findings, and hands off to a second agent that completes the implementation. The task becomes the shared memory between agents — no Slack messages, no long email threads, no lost context.
We've also opened Tasks to a small group of external users who've reported the same experience: their AI pipelines run more smoothly when every agent can reliably read and write tasks through a simple API. That's been validating.
Close + CTA
If you are building agent workflows and tired of passing state through Slack and text files, describe the program you are running. We built Tasks because our own agents needed a system of record.