# Why should an AI agent work in the same project as your team?

> An agent is more useful when its assignment, source context and result stay with the project. Here is what shared context changes, and what it should not grant.

A project decision is rarely just a sentence. It has a source, an owner, a deadline, and usually a follow-up. If an AI agent works in a separate chat, someone has to carry those pieces over by hand—and carry the answer back when the agent is done.

That is the practical reason to put an agent beside the project: keep the request and its result attached to the work they change. It is less about giving the agent a bigger prompt and more about avoiding another place where the team has to reconstruct what happened.

## A chat can answer; a project can keep the answer useful

Imagine a client project with a decision in its conversation, an open task, and a note from the last call. In a standalone chat, the agent sees only the material someone supplied or connected. A teammate still has to explain which project it concerns, find the source, and copy the result back to the right place.

In a project workspace, those records can stay connected. In Starlings, for example, a member can connect Claude over MCP to search and open records that member can already access. A shared Team agent follows a different path: it has its own identity, can be addressed in a project conversation, and can receive a task or issue as a hand-off. The conversation gives the agent the brief; the card gives the work a place and a status.

Those paths should not be blurred. A personal Claude acts with the connecting member’s authority. A Team agent is a separate roster member with a narrower, explicit agent surface. Neither should be treated as a universal account that can see every project.

## Shared context is useful when the work has a home

The project is a good place for an agent when the request changes something the team will need to find later. Examples include:

- turning a project discussion into a proposed task;
- summarizing a finalized call for the people working on that project;
- checking an open issue against a decision already recorded in the project;
- drafting a short internal brief from documents and history the requester can access.

These examples work because the source and the result have a relationship. A task belongs to a project; a meeting can be filed on a subject; a discussion has a project channel. A polished answer in an unrelated chat does not create that relationship on its own.

## Shared does not mean unrestricted

Giving an agent a place in the project should not mean giving it every record or letting it act without a boundary. Start with the smallest access and action surface that can complete one useful job. Make the source visible to the person who connects or assigns the agent. Keep consequential changes reviewable.

Starlings makes that distinction concrete. A member’s Claude reads as that member, and its write tools are hidden unless the member allows **Also write** during pairing. A Team agent receives a named hand-off; its reply moves the card to **Review**, where a person can inspect the result. A member can see the agent’s identity and activity in the shared conversation.

Meeting context also has a boundary. An agent can read a meeting artifact only after the meeting ends and only when the person’s access allows it. A non-owner needs the meeting filed on a subject they can see. Live audio, video and live transcripts are not agent context.

## A small example

**Hypothetical example:** after a project call, a consultant asks an authorized assistant to list the commitments in the finalized notes, show which lines support each one, and propose internal tasks on that project. The consultant checks the proposals, corrects anything uncertain, and approves only the tasks the team accepted.

The agent has helped with the hand-off. It has not decided what the client agreed to, granted itself access, or turned a suggestion into a commitment. The project record keeps the approved work beside its context.

If the agent’s output is hard to review, or the team cannot tell where it came from, the workflow needs a better source or a smaller assignment. Moving a vague request into a project channel does not make it precise.

## Try one project, one card

Choose a project with a recurring, low-risk piece of internal work. Give the agent one bounded assignment, name the source it should use, and say what a useful result looks like. Keep the first result in **Review**. After a few turns, ask whether the team spent less time finding context and checking where the work landed. If not, fix the workflow before expanding the agent’s access.

For setup details, see [how to connect Claude over MCP](/help/howto/connect-claude) and [how a shared agent joins a Team](/help/howto/connect-an-agent-as-a-team-member). For a concrete first workflow, read [what a small consultancy should automate first](/field-notes/what-small-consultancies-should-automate-first).

---

Canonical page: https://starlingshq.com/field-notes/why-agents-belong-in-the-same-project