More agents and more people

A second person changes the problem. Their agent may need a shared customer decision while their private conversation remains inaccessible.

By the end of this part, you will have a small sharing prototype, an explicit access policy and tests for both useful answers and information that must stay private. These are development checks; passing them does not certify a production system.

Decide what belongs to whom

Write down which information is personal, which belongs to a team and which sources the company provides directly. Decide who may read, share, correct and withdraw each kind.

Several designs can fit: a shared collection with access labels, separate personal stores with selected sharing, or a company knowledge service alongside personal memory. Choose from the work and permissions you need. A separate database alone does not settle authorization, and a shared database does not remove the need for boundaries.

Explain the policy before connecting real employee sources. Define what an admin can do through the app and what a server operator can technically access.

Build a small, disposable example

Use invented people and a few records. Give two coworkers different permissions around one customer. Add an agent with narrower access than its owner.

Ask your agent to help implement the chosen policy. Enforce it in code at the read and sharing boundaries. Models can help classify content, but a classification can be wrong; it cannot establish the caller's identity or replace authorization.

Sharing controls should explain what changes when someone opts out, withdraws an item or leaves. Define how retained copies and derived information are handled. Make uncertainty about whether something may be shared a reason to hold it back.

Check useful sharing and attempted leakage

Test both sides of the boundary:

• An authorized coworker can use a shared decision and see its attribution.
• An unauthorized coworker cannot obtain it through a direct question, search, source opening or an agent message.
• Revocation applies to existing connections as well as new ones.
• Withdrawal is handled across retained copies, indexes and derived summaries.
• A backup restore does not silently reinstate withdrawn access or deleted information.

An agent or person cannot unread information already delivered. Backups have their own retention and restoration behavior. Explain those limits honestly.

For agent-to-agent messaging, define recipients, permissions and the treatment of received content separately. Permission to send a message is not permission to read the recipient's sources or direct their agent.

Measure, then review the boundary

Score authorized work questions for each person's agents. Keep privacy-denial cases separate and review them by hand; any observed leak blocks use with real private data, regardless of the answer-quality average. A small clean sample is a starting point, not proof that every access path is safe.

Companies add operational and human responsibilities beyond a personal prototype. Team0's company install is one way to buy a maintained system in the company's cloud, with updates and support. The exercises here also support teams choosing to build their own.

Next, part 9: running it.

---

Build and measure your own setup with the companion skill. See the series. For a maintained company install, talk to Team0.