A task used to have one reader: the person who would do it. Today the same task is just as likely to be opened by a coding agent, a script that talks to an API, or a chat assistant that was asked to “pick up the next thing.” These two readers want very different things from the same card, and most task trackers make you serve both in a single description field.
TimeMagic is our attempt at a modern task management system, one built on the assumption that people and AI agents both work from the same list. The first concrete piece of that is AI Agent Context: a separate field on every task that is written for the agent and stays out of the human’s way.
One description cannot serve both readers
Look at what a person needs from a task: a short name, a sentence about why it matters, maybe a deadline. They already know the project. They do not need to be told which file the code lives in.
An agent arrives with none of that background. It needs the repository link, the folder to work in, the constraints that are easy to forget (“don’t touch the PDF export”), and a definition of done it can check for itself. Put all of that into the description and the task page turns into a wall of text that you scroll past every day. Leave it out and the agent guesses, or asks you the same questions again on every task.
The usual compromise is a description that is too long for the human and still too thin for the agent.
What AI Agent Context is
Every task has an optional AI Agent Context field, written in Markdown. Three things make it different from the description:
- It is collapsed by default. On the task page it is a single row, “View AI context”, with a small dot that tells you something is inside. It takes the space of one line until you open it.
- It is for agents first. The text is returned together with the task when something reads it through the API or through the MCP server, and Bot Leopold can read and write it too. The agent does not have to be told to look for it.
- A human can still read and change it. Open the row to see the rendered Markdown, copy it with one button, or edit it on the task form. Nothing is hidden from you; it is just not in your face.
It is optional, so tasks that need no briefing stay exactly as they were. The field takes up to 200,000 characters, which is far more than any briefing should need. It is never shown on the public report and estimation pages you share with clients.
An example: a coding task
On the task page the person sees the name, the description and one collapsed row labelled “View AI context”. Behind that row sits the briefing the agent works from:
## Where to work
- Repo: `github.com/acme/invoice-portal`, branch off `main`
- Controller: `app/controllers/invoices_controller.rb` (`#index`)
- Reuse `Invoices::Query` so filters apply to the export
## Constraints
- Stream the response, never build the whole file in memory
- Columns: number, client, amount, currency, issued_at, status
- Do not touch the PDF export
## Done when
- `bundle exec rspec spec/requests/invoices_spec.rb` is green
- Linked from the list page as "Export CSV"
None of this is something the person needs on screen. All of it saves the agent from reading half the codebase to find where to start.
Writing and editing it
On the task form, the field sits under the description as a collapsed “Add AI context” row, or “Edit AI context” when something is already there. Open it, write Markdown, save. What you typed stays in the form if you collapse the row or if validation fails on another field.
Through the API the field is called ai_context. Leaving it out of an update keeps the current text, sending a string replaces it, and sending null or an empty string clears it. That makes it safe for an agent to update other fields on a task without wiping the briefing.
What belongs in it
Things the person would never think to read, but the agent cannot do without:
- links to the repository, the branch, the design file, or the ticket the work came from
- the files and folders that matter, and the ones that must stay untouched
- conventions the project follows and commands that check the result
- acceptance criteria written so that a machine can verify them
It does not have to be code. A task for a content writer’s assistant can carry the link to the brand guide, the tone rules, and the list of pages the new text must not repeat. Keep passwords, tokens and other secrets out of it: the field is meant to be read by tools, so treat it like any other text you would hand to one.
Where the agent finds it
The field is part of the task, so it travels wherever the task goes:
- API: creating, reading, listing and updating tasks all include
ai_context. - MCP: asking for a single task returns the full text. Task lists return only a flag saying whether context exists, so a long list does not drown the agent in text it did not ask for.
- Bot Leopold: the assistant can read the context when you ask it about a task, and write it when you ask it to create or update one.
- Project copies: copying a project carries each task’s AI context with it.
There is also a TimeMagic skill for coding agents that knows about the field: it asks whether to add context when it creates a task, and checks before touching context that already exists.
Try it on one task
Pick a task you would hand to an agent tomorrow, open it, and write the briefing you would give a new colleague on their first day. Then let the agent read it from TimeMagic instead of from your chat history. The description stays short for you, and the context does the explaining for the agent.