How to connect an AI agent to your project

A solo professional already has an AI assistant: in the terminal it reads code, edits texts, and works through a list.

But it knows about the project plan exactly as much as you paste into it manually: copy the task list, paste it, explain the context — and repeat tomorrow.

In PRO-dela, a project can be opened to an external AI agent directly: using a personal token, the agent reads the project context, searches for tasks, creates them, and changes statuses. Let's break down what this gives you and where the boundaries lie.

Why an agent needs access to a project

The typical evening routine: export open tasks, explain to the agent what to do with them, paste the result back.

Every transfer is manual, and it is precisely these that eat up the benefits of automation: the agent itself is fast, but the transfer of data between it and the project is not.

Direct access changes the arrangement: the agent reads the current state of the project itself, so you don't need to explain to it what the platform already knows.

The task is formulated once — "look into the scope of work and prepare a draft of the missing tasks."

For a solo professional, this is the first real "colleague" working through a list: it doesn't make decisions, doesn't call the client, but does the mechanical part and doesn't get tired at ten in the evening.

Step 1. Issue a project token

In the project settings, an agent token is issued — a personal access key. The token is tied to one project and operates within the scope of your permissions in it: the agent won't get anything you yourself can't see.

The token can be managed: enabled and disabled without deleting, deleted permanently. This lets you "crack open" access for the duration of a task and close it afterward — without recreating the configuration.

Store the token the same way as a password: it grants access to project data. Don't paste it into chats, screenshots, or public repositories.

Step 2. Give the agent a task from the list

The agent connects from a tool you're used to — Claude Code, opencode, Codex — and sees the project context: the set of tasks, statuses, assignees, your permissions. The first task should be a read-only one: "describe the set of open tasks by topic."

Once you're sure the agent understands the project, entrust it with work from the list: creating a task or a list of up to twenty-five tasks at a time, changing a status, assigning an assignee.

Errors in names don't go through silently — when something is ambiguous, the agent receives a list of candidates and clarifies.

Give tasks the way you would to a junior colleague: a specific list, a criterion for the result, what to do when in doubt. Check the outcome the same way you would check their work.

Step 3. Check the result and close access

Checking the result is your part of the deal: created tasks are read with your own eyes, statuses are verified against the list. The agent doesn't make acceptance decisions and doesn't rewrite history — it works with the same task field as you and leaves the same traces.

After the work is done, the token is disabled with a single action. Returning to work means enabling the same token, with no new setup.

Once a month, it's useful to look at the list of project tokens: what's active, what's been forgotten and left enabled. Five minutes of hygiene — and access always matches the current tasks.

Example: evening backlog cleanup

A developer connects an agent to an online store support project. The task: read the open tasks, group them by topic, and create three missing tasks for the bugs from today's client email.

The agent reads the context, finds two of the three issues already filed, creates the third task, and proposes a wording for a fourth — a clarifying question for the client.

In the morning, the developer checks the result in two minutes: confirms two tasks, reformulates one.

This is a training example. What's telling isn't the volume — three tasks — but the absence of manual data transfer between the agent and the project: previously, this connection took more time than the work itself.

How this works in PRO-dela

An external agent connects via the MCP protocol with a project token. Every call goes through the platform's public API with the permissions of whoever issued the token: no separate "agent" authority exists.

The agent's tool catalog is — reading the context and task list, creating a single task and a list, changing status and assignee. The agent has no deletion; acceptance decisions and changes beyond the task field remain with the human.

The token is managed on the project: issuing, enabling, disabling, deleting. One token — one project; a separate one is issued for another project.

What most often gets in the way

The first mistake is giving the agent vague tasks: "tidy up the tasks" instead of a list of steps. The second is not checking what was created: the agent is careful, but not omniscient.

The third is keeping forgotten tokens enabled: access should live as long as the task does.

Frequently asked questions

Which agents are suitable?

Tools that work with MCP: Claude Code, opencode, Codex, and others. Connection is standard, via the server address and the project token.

Can the agent delete tasks or data?

No. Its tool catalog is limited to reading, creating tasks, and changing statuses and assignees; there are no deletions.

What does the agent see?

One project, the one the token was issued for — and only what's available to you in it. Other projects and companies are closed off.

Connect the agent to one project

Issue a token, give the agent a first read-only task, then — one task list to create. Check the result, disable the token, and decide whether an "evening agent" fits into your work rhythm.

Sign up for PRO-dela. Current terms of use are available on the pricing page.