---
title: What belongs in a shared Hub?
description: Sort a team's material by who reuses it and how fast it changes. What to write down in the Hub, what to reach through tools, what to restrict and what to keep out.
canonical_url: https://hubzoid.com/blog/what-belongs-in-a-shared-hub
last_updated: 2026-09-27
---

# What belongs in a shared Hub?

Sort a team's material by who reuses it and how fast it changes. What to write down in the Hub, what to reach through tools, what to restrict and what to keep out.

Foundations · Published 2026-09-25 · Updated 2026-09-27

Once a team decides to share context between its agents, the next question arrives quickly: what goes in?

> Put in too little and every agent rediscovers the basics. Put in too much and the Hub becomes a stale copy of systems the team already runs, holding material some people should never see.

Two questions sort most material:

- Will more than one agent, workflow or person reuse it?
- Will it still be true next month?

What passes both belongs in the Hub, written for people to read. What fails either one usually has a better home. This article walks through that sorting with an invented finance operations team at a company with two trading entities.

## One team's material, sorted

Here is how the invented finance operations team might sort what it has, and each row is explained below.

| Material | Where it goes | Why |
| --- | --- | --- |
| Close calendar, account codes, approval limits | Reference notes in the Hub | Reused everywhere, changes slowly |
| How to check a vendor bill or write an accrual note | Procedures in the Hub | The same steps, reused across requests |
| Public exchange rates | A tool anyone may use | Changes daily, needs no secret |
| Ledger entries | A restricted tool, granted to named people | Live and sensitive |
| Policy documents exported as text | A searchable folder in the Hub | Too long to curate, useful to search |
| Salary review notes | A separate Hub with its own access, or not at all | Not everyone who uses this Hub should see them |
| Chat conversations | With each conversation | A record of talk, not maintained knowledge |

## Slow-changing rules belong in the Hub

Terminology, rules, responsibilities and decisions change slowly and are needed everywhere. They are the core of a shared Hub, kept as short reference notes with one topic per note. For the finance team, that means:

- the month-end close calendar
- what each account code means
- purchase approval limits by role
- who owns each supplier relationship

Write each note so a person can read, check and correct it. A good note names its owner, the date it was last reviewed and the source it came from. The finance team's approval limits note, for example, says that the financial controller owns it, that it follows the current delegation of authority policy, and the date the limits took effect.

A note's short description matters more than it looks. The agent sees the name and description of every note and opens only the ones a question needs. "Purchase approval limits by role" will be opened for the right questions. "Finance policy" will be opened for every question, or for none.

## Live records stay in the systems that own them

A Hub does not need a copy of every business record. Balances, open orders and ticket queues change during the day, and a copy starts going stale the moment it is saved. The Hub reaches them through a tool instead. The agent asks the system that owns the answer, and a reference note explains how to read what comes back.

> If a file would need updating more than once a week to stay true, it belongs behind a tool.

There is a middle ground. Material that is too large or too raw to curate, such as policy documents exported as text or a copy of a code repository, can sit in a folder the agent searches as plain text rather than reading whole. There is no separate index to build or keep in step. The folder travels with the Hub like everything else.

## A rule and the steps that apply it are kept apart

A policy states a rule. A procedure describes how to carry out a task. Keeping the two apart means a good procedure can be reused without copying the facts it depends on.

The approval limits are a rule. Checking a vendor bill is a procedure:

- find the purchase order number
- compare quantities, prices and tax
- confirm the order was approved at the right level, by reading the approval limits note rather than restating the limits
- list every mismatch without correcting the bill

When the limits change, the team edits one note, and every procedure that relies on it follows. Hubzoid calls these procedures skills. The agent sees each skill's name and description and loads the full steps only when a task calls for them, so a Hub can hold many procedures without making every request heavier.

## Tools with consequences need a named permission

Some capabilities are sensitive by nature: reading the ledger, changing a supplier record, looking up payroll. In Hubzoid these become restricted tools. Each one runs only for the people and workflows an administrator has granted it in the Console, and every attempt, allowed or refused, is recorded.

The credentials those tools use are kept where the agent's own file reading cannot reach them, so the model sees the tool's result and never the key. The same reasoning rules out a common shortcut.

> A token pasted into a reference note is readable by everyone the note is shared with.

Not every tool needs a permission. A tool that fetches public exchange rates can be open to everyone who uses the Hub. But an open tool does not check who is asking, so any credential it uses should allow only what every user of the Hub may do.

## One brain does not mean one room for everyone

"One brain for your internal agents" is about providing context once, not about one global context that everyone can see. A Hub can serve a product, a team or a whole company. Finance and operations can each keep their own, with their own notes, tools and schedules, while a company Hub answers shared questions such as policies.

Several Hubs can sit behind one sign-in, where people see only the agents they have been granted. Inside one Hub, a narrower agent can carry its own instructions for a specific job while relying on the same shared notes. Scoping is how context stays reusable and safe at the same time: shared with the people and agents who need it, and no further.

## Some material stays out on purpose

Three kinds of material are the easiest to get wrong:

- **Material with a different audience** needs its own boundary, not a warning in a shared note. Salary review notes belong in a separate Hub with its own access, or nowhere.
- **Conversations are not knowledge.** Each chat keeps its own history, and a fact only belongs in the Hub once someone has written it down on purpose.
- **Workflow records** stay out too. Hubzoid keeps the record of what a scheduled workflow has already done separately from the Hub's notes.

## A shared Hub holds what the team would otherwise repeat

The test stays simple:

- If more than one agent, workflow or person will reuse it, and it will still be true next month, write it in the Hub with an owner and a source.
- If it changes daily, reach it through a tool.
- If it needs a key, restrict it.
- If some people should not see it, give it a Hub of its own.

[The Hub](https://hubzoid.com/docs/concepts/hub) explains how notes, procedures and tools fit together. For why every note needs a date, a source and an owner, read [the company brain](https://hubzoid.com/blog/the-company-brain).