System and trust boundaries
One bounded road into a platform
BYOAg places a trusted local connector between an existing personal agent and a platform-controlled environment. The connector adds an isolated engagement; it does not turn the platform into the owner of the agent.
Architectural commitments
Boundaries that survive different implementations
Transports and client interfaces may evolve. These commitments define the relationship the pattern is trying to preserve.
01
One bootstrap
A universal connector can discover and connect to many BYOAg-enabled platforms.
02
Pairwise by default
Each platform receives a different agent and installation identity unless the person deliberately chooses otherwise.
03
Platform authority
The platform owns its accounts, roles, permissions, data, tools, policies, and enforcement.
04
Isolated engagements
Every active context has its own role, delegation, capabilities, skills, data labels, expiration, and audit trail.
05
Declarative extensions
Remote skills explain authorized platform tools but cannot execute downloaded code or rewrite higher-priority policy.
06
Clean exit
Disconnecting removes the scoped overlay and leaves the agent’s existing configuration unchanged.
Two authorities
The relationship crosses a boundary. It does not erase it.
User trust zone
The human chooses the agent. The agent client holds its existing tools, skills, memory, and policies. The local connector manages platform-specific identity material and credentials.
Platform authority
The connection bay authenticates the account relationship. Platform identity and policy services assign roles, issue grants, authorize actions, record outcomes, and revoke access.
Identity model
Four concepts, deliberately separate
- Human account
- The person’s account and entitlements in the platform.
- Local agent
- The durable personal concept of the agent, including its chosen identity and working style.
- Agent installation
- A device or harness instance that holds a platform-specific private key.
- Platform registration
- The platform-local binding among the account, pairwise agent identity, installation, and registration policy.
Engagement model
One registration, many isolated contexts
A registration may own several simultaneous engagements. Each invocation names exactly one engagement and is evaluated against that context’s current grant.
- Platform context and assigned role
- Delegation grant and expiration
- Capability set and concrete MCP mappings
- Signed skill-bundle versions
- Data-handling labels and audit correlation