DEV Community: Filipp Mishchenko

Part 3: From an Agent-Ready Queue to a Scheduled AI Worker

Filipp Mishchenko — Mon, 20 Jul 2026 11:58:02 +0000

The Original Idea

The first version of Personal Task Assistant was built around one product idea:

Stop manually figuring out what to delegate to AI. Let the task system surface agent-ready work.

That idea is still the center of the project.

But the implementation has moved from "a task board with an AI queue" to
something more operational:

an agent can atomically claim work;
source ingestion can be retried without creating duplicate tasks;
MCP clients can operate the board without custom API glue;
the MCP tool surface has a repeatable evaluation process;
future Codex and Claude sessions are routed by AGENTS.md and project skills;
a daily ritual can write a deterministic digest and, when explicitly enabled, let Claude work the Codex queue through only the task tools.

The question changed from:

Which tasks can AI take?

to:

How can an agent show up every day, move safe work forward, and still leave the human in control?

Why a Queue Was Not Enough

The first public drafts focused on routing:

human-owned work;
Codex-owned work;
review-ready output;
blocked work;
unassigned work.

That split is useful, but it is not the full operating model.

Once the queue exists, the next problems appear quickly:

The agent needs a precise contract, not a UI to inspect.
Multiple runs should not accidentally take the same task.
Source adapters will retry messages, emails, or webhooks.
Agent tool descriptions need to be tested, not just written.
A scheduled worker needs hard limits in code, not only instructions in a prompt.

That is where the recent versions went.

Atomic Claim

Version 0.4.0 added:

POST /api/agent/claim

The agent no longer reads a list and hopes the first task is still available.
Instead, the server picks the top-ranked codex/backlog task, conditionally
moves it to in_progress, and returns it.

In SQLite this is a conditional update. In Firestore this is a transaction.

If another worker already claimed the task, the current worker tries the next
candidate. If nothing is claimable, the JSON API returns 404; the MCP tool
wraps that into a readable "No claimable task" message.

This matters even for a personal tool. As soon as you have scheduled runs,
manual starts, or multiple agent windows, "two agents took the same card" becomes
a real failure mode.

Idempotent Ingest

The same release added external_id.

Adapters can pass stable source ids such as:

telegram:<chat_id>:<message_id>:<line>
gmail:<thread_id>:<message_id>:<n>
jira:PROJ-42

Context ingest now reports repeated items as duplicates instead of creating new
tasks. Direct task creation with an existing external_id returns a conflict.

This is not a glamorous feature, but it is essential for real inbox and chat
automation. Polling jobs retry. Webhooks replay. Offsets get lost. The task
system has to survive that.

MCP Became the Native Agent Interface

Version 0.5.0 added an MCP server:

adapters/task_assistant_mcp.py

It wraps the JSON API as nine tools:

task_assistant_get_queue;
task_assistant_queue_summary;
task_assistant_claim_task;
task_assistant_finish_task;
task_assistant_create_task;
task_assistant_update_task;
task_assistant_list_tasks;
task_assistant_ingest_context;
task_assistant_due_reminders.

The intended workflow is:

read the queue
-> claim a task
-> do the work
-> finish the task
-> human reviews it in waiting_review

That last step is the product principle.

For AI-agent workflows, done is often the wrong state immediately after agent
execution. If an agent drafts an email, prepares a fix, writes notes, or finds a
blocker, the human usually still needs to accept the outcome.

So the normal terminal state for agent work is:

waiting_review

not:

done

Evaluating the Tool Surface

Once the MCP server existed, I needed a way to test whether an agent could
actually use it.

Version 0.5.1 added evals/:

a deterministic 16-task board;
10 read-only questions with single verifiable answers;
a free verify_answers.py ground-truth check that uses the real MCP server;
an optional LLM evaluation harness that gives Claude only the MCP tools;
a write-loop check for claim -> in_progress -> finish -> waiting_review.

The goal is not to prove that one model is smart.

The goal is to test whether the tool contract is clear enough.

If an eval fails, the useful question is often:

Is the tool name misleading?
Is the output too verbose or too sparse?
Does the error message tell the agent what to do next?
Does the queue summary expose the right counters?
Is the workflow encoded in the tools or only implied by docs?

That is a much better feedback loop than manually watching an agent struggle.

Agent Playbooks

Version 0.5.2 added AGENTS.md and project skills under .claude/skills/.

This sounds like documentation, but it is more specific than that. It is an
operating contract for future agents working in the repository.

Examples:

If an agent is about to work tasks from the board, read task-board-worker.
If it is touching the daily automation, read daily-task-ritual.
If it is changing MCP tools, read mcp-tool-change and run the eval gate.
If it is touching schema, use Alembic only.
If it is shipping a change, bump the version and update the changelog.

For a project that is developed with both Codex and Claude, this matters. The
repo needs to carry not just code, but repeatable agent behavior.

The Daily Ritual

Version 0.6.0 added the daily automation layer.

The schedule is not auto-installed on upgrade. The user deliberately installs
it with automation/install.sh, because it schedules an agent that acts on
their behalf.

It has two deliberately separate parts.

The first part is deterministic:

automation/daily_ritual.py

It reads the board and writes a dated digest:

overdue;
waiting for review;
blocked;
unassigned;
due within 24 hours;
agent-ready queue.

It never mutates the board.

That means you always get a board report even if the agent layer is off or
fails.

The second part is opt-in:

automation/work_loop.py

When DAILY_RITUAL_WORK=1 and ANTHROPIC_API_KEY are set, Claude gets only the
task_assistant_* MCP tools and the worker instructions.

The safety rails are enforced in code:

no shell;
no repository access;
no web access;
only the Personal Task Assistant MCP tools;
attempts to set status=done are rejected;
--max-tasks caps claims per run.

So the daily worker can claim work, add findings, update the task, and send it
to waiting_review. It cannot silently close the task.

The Current Boundary

The architecture now looks like this:

web UI = human operating surface
JSON API = integration contract
MCP server = native agent contract
evals = tool-surface quality gate
AGENTS.md + skills = project memory for future agents
daily ritual = scheduled report and optional bounded worker
human review = final acceptance

This is less flashy than a fully autonomous agent with every possible tool.

But it is a safer boundary for a personal operations system.

The agent can move work forward. It can ask for input. It can create reviewable
output. It cannot pretend that a human accepted the result.

What Changed Technically

The recent releases also hardened the project:

Alembic migrations replaced ad-hoc schema creation;
the pytest suite covers task CRUD, auth, queue behavior, ingest deduplication, migrations, MCP tools, and the daily ritual;
Ruff and GitHub Actions run lint and tests;
Local Mode auth is loopback-only;
Firestore reads avoid pulling completed tasks during agent polling;
Google Sheets history writes moved off the request path;
the Docker image runs as a non-root user.

None of that is the headline feature. All of it matters if the app is supposed
to run every day.

Try It Locally

The local setup path is still intentionally boring:

git clone https://github.com/J3d1-fm/Personal-Task-Assistant
cd Personal-Task-Assistant
python3 scripts/setup_wizard.py

That starts Local Mode on:

http://127.0.0.1:8000

For an MCP client, run the app and register:

claude mcp add task-assistant \
  -e TASK_TRACKER_URL=http://127.0.0.1:8000 \
  -e TASK_TRACKER_API_KEY=<key> \
  -- /path/to/repo/.venv/bin/python /path/to/repo/adapters/task_assistant_mcp.py

The useful first test is simple:

Read my task queue, claim the next Codex task, and finish it to review.

What I Learned

The most useful product primitive was not "AI chat".

It was:

task status + next-action owner + review handoff

The most useful engineering primitive was not "give the model more tools".

It was:

give the model fewer tools, make them explicit, and evaluate the contract

That is where Personal Task Assistant is now heading.

Development continues beyond 0.6.0. I will share the next changes separately instead of mixing several releases into one article.

Repository:
https://github.com/J3d1-fm/Personal-Task-Assistant

If you are using Codex, Claude Code, or another agent as part of real work, I
would like feedback on the boundary: what should an agent be allowed to do
unattended, and what should always come back to human review?

What I Learned After Running My AI Task Queue on Real Work

Filipp Mishchenko — Sat, 13 Jun 2026 08:39:06 +0000

I previously open-sourced Personal Task Assistant:

https://github.com/J3d1-fm/Personal-Task-Assistant

The first version was built around a simple idea:

Stop manually deciding what to delegate to AI.

The app separates work into queues:

human-owned tasks;
AI-ready tasks;
tasks waiting for review;
blocked tasks;
unassigned tasks that still need triage.

After running it on real work streams, the biggest lesson is that the task list
is not the hard part.

The hard part is ingestion.

Real work streams are messy

Tasks do not arrive as clean task objects.

They appear in:

emails;
Slack threads;
Telegram-style chats;
GitHub notifications;
documents;
follow-up messages inside old conversations.

If I import everything, the task system becomes noise.

If I import too little, important work stays hidden in inboxes.

So the product direction changed from "store tasks" to "decide what deserves to
become a task."

The current ingestion contract

The import flow now follows a stricter pattern:

Read recent source items.
Check exact timestamps instead of trusting broad date filters.
Compare against existing tasks, including completed ones.
Create only normalized actionable tasks.
Report source status separately.

That last point matters.

A source can be:

checked, with no actionable work;
unavailable because auth is broken;
failed because the connector did not start;
checked and converted into new tasks.

Those are very different outcomes.

An AI system should not flatten them into "nothing found."

Dedupe matters more than it looks

The first naive version of this kind of workflow is easy:

"Search recent messages and create tasks."

That works until the same work appears in several places:

a GitHub review notification and an email;
a Slack follow-up and an existing task;
a same-day email that is older than the actual cutoff;
a reminder in a thread that already produced a task.

The system now dedupes against existing tasks before creating new ones.

It also treats follow-up messages carefully: a follow-up inside an old blocker
thread should update the existing task unless it introduces a materially new
action item.

This makes the queue smaller, but much more useful.

"Unavailable" is a valid result

One of the most useful changes was making source health explicit.

If Gmail auth is expired, that should be reported as an unavailable source.

If a chat connector cannot start, that is a failed source.

If a source was checked and had no actionable messages, that is a normal empty
result.

Those states should not look the same.

For a personal AI workflow, this is important because the user needs to know
whether the assistant actually checked the source or silently skipped it.

The human remains part of the loop

The execution side already supports an agent handoff:

a worker can claim AI-ready tasks;
multiple workers can run in parallel;
each worker can report structured results;
if it needs a decision, access, or missing context, it returns a needs_input question.

Running the product on real work made the same principle clearer for ingestion:

The assistant should act when the task is clear.

It should ask when a human decision is needed.

It should say exactly what is blocked when it cannot continue.

What I would build next

The most useful next work is not another generic AI chat interface.

It is small, reliable source adapters:

Slack;
Telegram;
Gmail;
Linear;
Jira;
Asana;
YouTrack;
Trello;
Google Calendar.

Each adapter should be boring in the best way:

read only what it needs;
dedupe before creating tasks;
avoid private credentials inside the core app;
report source status clearly;
create only actionable work.

The current takeaway

After dogfooding the project, I think the useful abstraction is not just a task
tracker.

It is a human/AI work surface with explicit boundaries:

what the human owns;
what an AI agent can take;
what waits for review;
what is blocked;
which source was checked;
which source needs reconnecting;
what question needs a human answer.

That is where AI agents become more practical for real work.

Not by pretending to be autonomous everywhere.

By knowing when to act, when to dedupe, when to report, and when to ask.

I would like feedback from people building with coding agents or personal
automation:

Which adapter would be most useful first: Slack, Telegram, Gmail, Linear, Jira,
Asana, YouTrack, Trello, or Calendar?

And where should the line be between "agent can act" and "agent must ask"?

Stop Figuring Out What to Delegate to AI

Filipp Mishchenko — Fri, 05 Jun 2026 12:46:22 +0000

I built an open-source task queue that separates human work, AI-ready work, blocked work, and review-ready output.

The Problem

Most AI tools still assume the human knows exactly what to ask.

That sounds reasonable until you use coding agents, inbox automation, Slack
summaries, meeting notes, and personal task capture every day. The bottleneck is
not always execution. Often, the bottleneck is deciding what should be delegated
to AI in the first place.

I kept running into the same operational question:

Which of these tasks should I do, and which ones can an AI agent take from here?

That question is surprisingly expensive.

It requires reading context, identifying the next action, checking whether a
credential or decision is missing, deciding whether the result needs review, and
only then assigning the work to a person or an agent.

So I built Personal Task Assistant.

The core idea is simple:

Stop figuring out what to delegate to AI. Let the task system surface AI-ready work.

What It Is

Personal Task Assistant is an open-source interface for collaboration between a
person and an AI agent.

It turns work into an operational queue with clear ownership:

tasks for the human;
tasks an AI agent can execute;
tasks waiting for human review;
blocked tasks;
unassigned tasks that still need triage.

It is not trying to replace Jira, Linear, Asana, YouTrack, Trello, Slack,
Telegram, or email.

Instead, it exposes a small task model and JSON API so user-owned adapters can
bring tasks in from those systems.

Why This Needs a Different Model

A normal task tracker answers:

What needs to be done?

An AI-assisted workflow needs another question:

Who should do the next step?

That second question changes the product shape.

A task can be technically simple but blocked by a missing decision. Another task
can be complex but fully agent-ready. A third task may already be finished by an
agent but should not be marked done until a human reviews the output.

That is why Personal Task Assistant tracks both status and next-action owner.

Statuses:

backlog
in_progress
waiting_review
blocked
done
cancelled

Owners:

me
codex
unassigned

The value is not the labels themselves. The value is the filtered queue:

What do I need to do?
What can the agent do?
What is ready for review?
What is blocked?
What is overdue?

The Agent Queue

The important endpoint is:

curl "$TASK_TRACKER_URL/api/agent/queue?assignee=codex&sort=smart&limit=25" \
  -H "Authorization: Bearer $TASK_TRACKER_API_KEY"

Example response:

{
  "summary": {
    "active": 42,
    "overdue": 3,
    "due_soon": 4,
    "codex_ready": 12,
    "human_input": 18,
    "review": 5,
    "blocked": 2,
    "unassigned": 1
  },
  "tasks": []
}

This means an agent does not need to scrape the UI or read every task. It can
ask for an execution queue.

Ingesting Work From Context

Agents or adapters can send extracted tasks through the context-ingest endpoint:

curl -X POST "$TASK_TRACKER_URL/api/agent/ingest/context" \
  -H "Authorization: Bearer $TASK_TRACKER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "origin": "email",
    "source_name": "Gmail thread from Alice",
    "source_url": "https://mail.google.com/...",
    "source_context": "Alice asked for revised numbers by Friday.",
    "tasks": [
      {
        "title": "Send Alice revised numbers",
        "assignee": "me",
        "priority": 2,
        "reminder_at": "2026-05-07T09:00:00Z"
      }
    ]
  }'

The same pattern works for Slack, Telegram, Linear, Jira, Asana, YouTrack,
Trello, meeting notes, or any other source.

The project intentionally does not ship with built-in credentials or universal
source clients. The safer pattern is to keep adapters small and owned by the
user.

Local Setup

The fastest setup path is:

git clone https://github.com/J3d1-fm/Personal-Task-Assistant
cd Personal-Task-Assistant
python3 scripts/setup_wizard.py

Manual setup:

python3 -m venv .venv
. .venv/bin/activate
pip install -r requirements.txt
cp .env.example .env
uvicorn app.main:app --reload

Then open:

http://127.0.0.1:8000

The local setup uses SQLite. The intended hosted shape is Cloud Run plus
Firestore, with secrets stored outside the repository.

Architecture

The current MVP is deliberately small:

FastAPI serves the web UI and JSON API.
SQLite stores tasks locally.
Firestore is supported for Google Cloud deployments.
Google OAuth can protect the browser UI.
Bearer-token auth protects API clients.
Reminder polling can query /api/reminders/due.
Agent clients can read /api/agent/queue.

The data model stays compact:

title and description;
status;
assignee;
origin;
priority;
due date;
reminder date;
source name, source URL, and source context.

If a task does not include a due date, the server estimates one from priority:

P1: about 1 day;
P2: about 3 days;
P3: about 7 days;
P4: about 14 days;
P5: about 30 days.

It is not meant to replace real deadlines. It is meant to prevent important
captured tasks from silently aging without a date.

What I Want Feedback On

The most useful feedback right now:

Is the human/agent ownership model clear?
Is waiting_review the right default state for completed agent work?
What should the first real adapters be: Slack, Telegram, Gmail, Linear, Jira, Asana, YouTrack, or Trello?
Should the agent queue expose more ranking information?
What would make the local setup easier?

Why I Think This Layer Matters

AI agents are getting better at execution.

But execution is only one part of the workflow. The harder daily problem is
routing work correctly:

delegate this;
do this yourself;
review this;
unblock this;
ignore this.

That is why I think the next useful layer around agents is not another chat
window. It is a delegation layer.

Personal Task Assistant is my first open-source attempt at that layer.

Repository:
https://github.com/J3d1-fm/Personal-Task-Assistant