What is a Team and what are its Responsibilities?

What does a Team actually watch?

The tools that feed it. A Sales Team reads HubSpot, Gmail, Stripe, and the Calendar. An Engineering Team reads Linear, GitHub, and Sentry. Each Team shows its watch in three registers:

• Watching: the live signals it is tracking, the pipeline, the release, the queue.
• Weighing: what it is currently thinking about, with its read and its confidence.
• Next: what it intends to do, within the autonomy it has earned.

Alongside those, the core numbers stand against goal, and the few decisions that need a person sit where you cannot miss them. A Team page is the answer to “where does this part of the business stand” without asking anyone.

What are Responsibilities?

The editable statement of what the Team is on the hook for. Not a config file, not a prompt you engineer: a plain mandate, written in your words. “Keep the pipeline moving, flag deals that stall, and make sure every demo gets a same-week follow-up” is a perfectly good set of Responsibilities for a Sales Team.

The agent learns the workflows across your tools to deliver on that mandate, and it gets better at it over time. When the business changes, rewrite the Responsibilities and the Team reorients. How it delivers, the method it learns along the way, lives in its Playbook.

Which decisions come to you?

The consequential ones, and each Team keeps that list short and visible. Discounting beyond the usual range, a reply to an angry customer, anything irreversible: the Team stops, proposes with its reasoning and confidence, and waits. Those items land amber in your Feed, where you approve, decline, or talk them through.

Everything below that bar, the routine and reversible work, the Team handles and logs. The boundary between the two is not fixed: it moves as the Team earns autonomy, and it never moves past the permanent floor on irreversible and high-blast actions.

How do Teams keep everyone on the same page?

Every Team publishes what it finds to everyone’s Front. Sales sees what engineering is shipping. Engineering sees what sales is asking for. Support sees the bugs going out. When one Team depends on another, the dependency is on the page: a stalled deal points straight at the open issues blocking it.

That shared picture is the part no single-tool agent can offer, because no single tool can see it. One agent, one memory, every Team publishing to the same page.

When should you add a Team?

When a part of the business deserves its own watch. New product line, new market, a function that just got its first hire: add a Team, give it Responsibilities, connect anything new it should read. It looks like every other Team immediately, with no setup project. Team count is generous on every plan; the pooled credit budget is what scales, not permission to organize your business properly.