Bring your own AI agent: what actually carries over?
Separate the model, runtime, session, memory, identity, and permissions before connecting an agent to shared work.
Bringing your own AI agent means connecting an agent you already operate to another work surface. The useful question is what the connection preserves: your model account, runtime, existing session, selected memory, agent identity, or permission boundaries. Choosing the same model in two apps establishes none of the other five.
Imagine a coding agent that already understands your repository. You want a teammate to ask it about a proposed change from a shared workspace. There are at least three possible implementations. The workspace might start a fresh model conversation, dispatch a task to your local coding runtime, or continue a particular existing session. Each can be useful. Each carries a different amount of context and authority.
Test six kinds of continuity
| What you want to keep | Evidence to request | What does not prove it |
|---|---|---|
| Model account | Which account receives usage and which model actually runs | A vendor name in a model picker |
| Runtime | The process or harness handling tools and execution | A chatbot using the same base model |
| Session | A stable session reference and a successful follow-up in that context | A new task containing a summary |
| Memory | The specific facts or files transferred, with provenance and scope | A promise that the agent “remembers” |
| Identity | Attributed messages and actions tied to the same agent | A reused display name |
| Authority | Which account and grant authorize each consequential action | Access to a channel containing the request |
Treat an undocumented field as unknown. A product can intentionally provide fresh sessions while preserving your tools and instructions. That is a legitimate design, provided the boundary is clear.
A workspace connection and persistent memory solve different problems
Nebula documents external coding agents↗ running on a personal computer or cloud device using the operator's plan or API key. Its placement rules distinguish personal-computer DMs from channel participation through cloud devices. Those details help you evaluate where execution happens; they do not establish that an arbitrary existing desktop session will resume.
Letta's stateful-agent model↗ treats persistent agent state as a first-class concern. Persistent memory still needs a separate connection and permission model to participate in a destination app. Memory continuity and app membership are separate requirements.
These are documented examples reviewed on October 2, 2026, rather than a hands-on interoperability comparison. For a product selection, verify the exact surface and version you will use.
Run a small portability test
Start with a disposable project and a harmless fact, such as an invented release label. Record the original agent's session reference. Connect the destination surface, ask about the label, and inspect how the answer was produced. Did the destination continue the original session, read a shared file, receive a summary, or fail to receive the context?
Then test the sharing boundary with two artificial facts: one explicitly shareable, one explicitly private. Check what is placed in the task brief and what the destination user can read. Do not test with a real secret. A correct answer to one question is not proof that all private information remains isolated; inspect the transfer mechanism and its permissions.
Finally, disconnect the runtime. Determine whether a new request is rejected, queued, or accepted without execution. Reconnect and inspect the original request before resubmitting it. The distinction between a recorded request and a finished result matters as much as the initial connection.
Where OpenScout fits
OpenScout provides a local broker for addressing agents, requesting owned work, and following its recorded lifecycle. A project-and-harness request can start work without pretending to transfer the initiating chat. An exact continuation should use the returned work or session handle. See the routing model↗ and runtime sessions↗.
OpenScout does not promise universal personal memory portability or independent membership in every app. Its current posture is high-trust local developer pilots. Model providers and enabled bridges still receive the task data you send through them.
Use the handoff brief builder to specify the context, scope, and return artifact before trying a connection. The protocol explorer explains which interface crosses each boundary. If you only need a reviewer for a local change, start with the Claude Code and Codex walkthrough.