Project
The active work context keeps the relationship relevant and bounded.
Interaction model
How an agent enters an environment
A BYOAg environment can offer an Agent Docking Bay: a user-friendly way to connect a personal agent to an application. The user should not need to understand APIs, URLs, or HTTP requests to begin.
-
-
Agent Docking Bay
A clear entry point helps the person start without handling transport details.
-
Connected personal agent
Pairing and permission establish only the authority needed for the work.
-
Application operation
The application exposes remote capabilities while retaining its own rules and harness.
-
Result and continuation
The person receives status, receipts, and a path to review or revoke the relationship.
Agent Docking Bay
A connection flow a person can understand
An application can provide a ready-to-paste magic prompt that tells a personal agent how to initiate the connection. The app can visibly show that it is waiting for, and then has established, the connection.
A short pairing code entered by the human can confirm that the user is present on both sides. From there, the project can set the permission contract, make remote capabilities available, and support operation, audit, and revocation.
GET and POST are examples of an initial web-based implementation. They are not the only transport mechanisms BYOAg could ever support. The pattern is about the relationship between user-owned agents and environment-defined work, not about one mandatory protocol stack.
Evolving terminology
These draft concepts are intentionally lightweight while prototypes and discussion shape the pattern. Browse the glossary for concise definitions and their role in a BYOAg implementation.
Projects are the trust boundary
Connections do not belong only to the agent or only to the application. They belong to a project. A project can isolate the connection, permissions, shared context, operating prompts, scheduled tasks, and audit history.
A user can switch into a BYOAg-enabled school management project, delegate work to an agent, or schedule weekly student reminders, then return to other work without cross-project context leakage.
Remote capabilities, not local tools
An application may expose capabilities through authenticated API endpoints. An agent can reason about them as available capabilities, but they are not necessarily local tools registered inside the agent's own tool registry.
They are remote actions performed through the connected application. This distinction helps agent harnesses with strict tool registries avoid treating every remote endpoint as a locally callable tool.