Draw the boundary before you build the agent

Two agents in the same company. One helps the sales team research leads. The other helps finance reconcile payments. They were built a month apart by different people, and they have one thing in common: both were connected to everything, because that was the quickest way to get them working.

Nothing has gone wrong yet. But the sales agent can read the ledger, the finance agent can read every prospect's email thread, and neither needed to.

Agents inherit their surroundings

It is natural to think of an agent's access as something you decide agent by agent. In practice it is decided by where the agent sits. If connections are shared across the whole organisation, every new agent starts with the union of everything anyone has ever connected - and trimming that back, one agent at a time, is work nobody gets around to.

The fix is to make the boundary a thing in its own right, and to draw it first.

What a domain is

In Yekar.AI that boundary is called a domain. A domain is an area of the business - sales, finance, support, whatever lines your organisation already draws. Agents live inside one. So does the shared connection its agents can act through, and what an agent can read is scoped to the domain it belongs to.

The effect is that the default is narrow. A new agent in the finance domain can reach what finance has connected. It does not see the sales team's inbox - not because someone remembered to exclude it, but because it was never in scope.

Draw them where responsibility already sits

The most common mistake is to treat domains as a technical grouping - one per integration, or one per project. The lines that hold up are the ones your organisation already has: who owns this data, and who answers for it when something goes wrong.

• If two groups of agents have different owners, they are different domains.
• If two groups should never see each other's data, they are different domains.
• If neither is true, they are probably one domain, and splitting them just adds places to look.

It pays off when you grow

With three agents, none of this feels necessary. With thirty, it is the difference between answering "what can touch customer payment data?" by looking at one domain, and having to open every agent you run.

It also makes handing things over possible. A team can be given its domain and left to build inside it, without anyone reviewing each new agent for what it might reach. The boundary did that review once.

So before the instructions, before the tools, before the first test conversation: decide where the agent lives. Everything else is easier to change later.