AI Task Management for Teams: One System for People and Agents

An AI task management system for a team that includes agents is one store where every task lives, whoever created it: a person typing into a dashboard, an email forwarded to an inbox, or an agent that found something at 3am. The rule that makes it work is blunt. If a task is not in that store, it does not exist, and no agent is allowed to keep a list of its own on the side.

The reason this suddenly matters: Microsoft’s 2026 Work Trend Index, published 5 May 2026 from a survey of 20,000 knowledge workers in 10 countries, reported 15 times more active agents inside Microsoft 365 than a year earlier. Every one of those agents produces work that someone has to own. Most teams are about to discover that their task tool was designed for people who type.

This is the second post in our series on the governance layer that runs our own fleet. The first post summarised the task backbone in one paragraph. This one opens it up: how a task gets in, how it avoids being created thirty times, and what happens when nobody obviously owns it.

Why agents break an ordinary task tool

A project tool assumes each task is created once, by a person, on purpose. An agent that runs every morning breaks all three assumptions. It creates tasks on a schedule, it sees the same problem again tomorrow, and it has no judgement about whether yesterday’s task already covers it.

Point a daily agent at a normal task board and within a month you have thirty copies of “invoice overdue” for the same invoice. People stop reading the board, and the agent’s one useful finding drowns in its own repetition. The problem is structural, and it gets worse with every agent you add.

One intake door, no direct writes

Agents in our fleet never write to the task table. They send each task to one intake endpoint, signed with their own credential, and the endpoint decides what to do with it. Every tomte, our word for one production agent with one defined job, uses the same door.

A task arrives with a small, fixed set of fields: which registered source sent it, a title, a description, who it is for (a named person, an email, or a role), whether it is business critical, a link back to the record that caused it, and a dedup key. The endpoint validates all of it, resolves the owner, and replies with the task’s identifier and who it landed on.

Humans use the same store through different lanes. A poller reads a shared task inbox every few minutes and turns each email into a task with the source recorded as email. The dashboard writes through the same core path. So does the numbered reply format people use to answer the daily decision batch. There is no second table for “human tasks”.

The dedup key is the whole trick

Every task a source sends carries a key that the source chooses and that means something to it: an invoice number, a lead ID, a page URL. The store holds a uniqueness rule on source plus key. When a daily agent sees the same overdue invoice tomorrow, it sends the same key, and the existing task is refreshed in place rather than duplicated.

Status changes work the same way. When the underlying thing moves, the source re-sends the task with the new status under the same key. A lead that was won becomes a completed task. Nothing closes automatically behind the source’s back, which is deliberate: the system that knows the truth is the one that has to say so.

That last rule has a cost we learned about the hard way. Our highest-volume task source was, for a while, one-way. It created tasks and never updated them, so work that had been resolved elsewhere sat open in the backbone indefinitely. Nothing errored. The board simply filled with finished work until someone built the missing sync. A dedup key prevents duplicates. It does nothing about silence.

Unassigned is an answer, a guess is not

The part most task tools get wrong with agents is ownership. An agent often knows the role a task belongs to (“whoever handles payables”) and not the person. The tempting fix is to pick the first person who holds that role.

We did that, and a task landed on the wrong person at the wrong company in our group. The rule now is enforced at the database, below every agent, so no single integration can skip it: a human-owned task must resolve to one active, real person. If the assignee is ambiguous, inactive or external, the task goes to a named fallback owner and is flagged as needing reassignment. It is never silently guessed.

This sounds like bureaucracy until you look at the survey data. The Cloud Security Alliance’s January 2026 survey of 228 IT and security professionals, published in March and commissioned by Aembit, found 31% of organisations run agents under a human user’s identity. When an agent’s actions and a person’s actions share a name, “who owns this task” has no reliable answer anywhere downstream.

What every task carries

Field	What it answers	Why agents need it
Source	Which system or lane created this	Tells you which agent to fix when tasks go wrong
Dedup key	Is this the same thing as yesterday	Stops a daily agent flooding the board
Owner	One real, active person or agent	Unresolvable owners are flagged, never guessed
Link back	The record that caused the task	Lets a person check the claim in one click
Business critical	Does this need a senior human decision	Everything else is kept out of the decision queue
Definition of done	What evidence closes it	Marks whether a person wrote it or an agent drafted it

The business-critical flag is the anti-noise gate. A task that asks for approval but is not flagged critical is downgraded to an ordinary task for its owner, so agents cannot fill a senior person’s queue by labelling everything urgent. The money, people, credentials, legal and spend categories need an explicit confirmation even after a decision is given.

Closing a task needs evidence, not a status

Anyone can mark a task complete. In the backbone that is only a claim. A task with a checkable definition of done (a URL that returns live, a file that exists, a row that was written) is verified by a separate checker before it counts as done anywhere downstream. The follow-up side of this, chasing stalled work and checking the evidence, is its own agent, covered in how our follow-up agent verifies work actually shipped.

Cancellation turned out to need the same discipline. An internal review of automatically cancelled tasks found that most had no person and no reason behind them. A source’s background sync had been closing tasks underneath the people working on them. Cancelling now requires a reason, and cancelling a business-critical task waits for a human.

What we got wrong

Two failures are worth naming because neither looked like a failure. For a period, the path that updates an existing task returned a server error for every source, because of a type bug in one function. New tasks still arrived. Updates quietly did not. The only symptom was a board that slowly went stale, and it took a person noticing that to find it.

The broader lesson matches what EY reported on 15 September 2026 from 202 senior decision-makers: 49% have not updated their governance for agentic requirements. Our task system was built for people first and adapted for agents second, and each gap above was found after the fact. Microsoft’s report frames the question as holding humans accountable for the work agents execute. A single store, with a real owner on every row, is the minimum structure that question needs.

What this costs to set up

For a small team, the core is an afternoon of design and a week of build: one table, one intake endpoint, a uniqueness rule on source plus key, an owner check that refuses to guess, and a link back on every row. The expensive part is discipline afterwards, making sure every new agent uses the door and every source closes what it opens.

That discipline is what our Fractional AI Officer retainer runs month to month, and our own agent fleet is where it is proven. Send us a list of where tasks live in your company today, including the inboxes and spreadsheets nobody admits to. We reply in writing within one business day, no meeting. Start async.