{"slug": "bring-your-own-ai-agent-everywhere", "title": "Bring Your Own AI Agent Everywhere", "summary": "AgentPort, a new browser-based platform, lets users connect their own AI agents to applications through scoped grants and end-to-end encrypted sessions, positioning itself against Composio and Brave Leo's Bring Your Own Model. The company argues that users should own their AI agent and subscription, with applications lending session-scoped capabilities rather than building their own copilots.", "body_md": "# Bring Your Own AI Agent Everywhere\n\nAgentPort connects one user-owned agent to application capabilities through scoped grants and an end-to-end encrypted session. The browser is its first public surface.\n\nEvery new app seems to come with the same offer: pay another $20 a month for its AI feature.\n\nA writing app wants one subscription. A task app wants another. A research tool wants a third. Each gives you a new chatbot with no memory of the work you did elsewhere. Each asks you to trust a new company with your prompts and data. Cancel the app and the agent goes with it.\n\nEnough.\n\nI want one AI subscription. I want one agent that knows how I work, runs where I choose, and comes with me into every application.\n\n\"Bring your own agent everywhere.\"\n\n## The user should own the agent\n\nMost AI products bind the agent to the app. The app chooses the model, pays for inference, stores the chat, and charges the user for access. This repeats the same stack in every product.\n\nThe split should be much simpler:\n\n- The application supplies the capabilities: read this document, update this task, search this catalog.\n- The user supplies the agent: their model, subscription, memory, prompts, and tools.\n\nThe application lends a small set of capabilities for one session. The user's agent does the work, then disconnects.\n\nThis is what AgentPort does.\n\n## The competition is an ownership model\n\nThe market is building several answers to the same problem. App teams add their own copilot. Browser teams add one assistant that can see many pages. Integration platforms give an agent a catalog of SaaS APIs.\n\nThese are real alternatives. [Composio](https://docs.composio.dev/docs) lets existing agents use authenticated tools across more than 1,000 apps. It solves part of the portability problem.\n\n[Brave Leo's Bring Your Own Model](https://brave.com/blog/byom-nightly/) is the closest useful comparison I have found. It lets a user connect a local model, a remote endpoint, or a third-party API straight to Leo. Requests can bypass Brave's servers. That is real user control, and AgentPort should not pretend otherwise.\n\nBut a model is not an agent. Brave's BYOM contract is an OpenAI-compatible model endpoint; it does not standardize portable agent identity, memory, MCP servers, files, runtime, or approval rules. Brave lets the user bring inference into Brave's assistant. AgentPort lets the user bring the assistant they already run into a capability surface that another application owns.\n\nComposio reaches the other side of the problem. It gives an agent tools and authentication for outside services. That is useful when the agent starts the interaction and the service has a suitable API. AgentPort lets the application start a live session and lend the agent its current, surface-local capabilities. A WebMCP tool can act on the document already open in the tab without turning the whole product into a remote API or handing an integration platform the user's account token.\n\nThe difference becomes clearer when ownership is written down:\n\n| Approach | What follows the user | Who controls the agent | How the application becomes usable |\n|---|---|---|---|\n| App copilot | an account and chat history inside one product | the application | the application builds the whole agent stack |\n| Browser assistant | browser context across pages | the browser vendor | the browser reads or drives the page |\n| Bring your own model | a model endpoint or API key | the host assistant still owns the loop | the host assistant supplies its own capabilities |\n| Agent tool platform | an agent plus connected account grants | the agent builder or user | a platform supplies API tools and OAuth connections |\n| AgentPort | the whole agent: runtime, memory, prompts, tools, and subscription | the user | the application lends a session-scoped capability surface |\n\nThat ownership split is the claim:\n\n- the user chooses and owns the agent;\n- the application defines the actions it is willing to lend;\n- the wallet grants a narrow, expiring connection between them;\n- the relay cannot read the session;\n- the application never receives the user's model key or inference bill.\n\nEach part exists elsewhere. I have not found another system that joins all five around a user-chosen remote agent. This is a claim someone can disprove: show me an open system where any application can lend its own bounded capabilities to the agent a user already runs, with consent at the user's key and sealed transport through the middle.\n\nThe direct competition is any product that becomes the permanent owner of the user's agent relationship: the app, the browser, or an integration cloud. AgentPort wins only if users value carrying their existing agent more than they value an assistant bundled into each surface.\n\n## WebMCP gives a web app a voice\n\nThe web already has a draft answer for how a site can describe its actions. It is called [WebMCP](https://webmachinelearning.github.io/webmcp/).\n\nWebMCP lets a page say, in a form an agent can use: “Here are the tools available here.” A writing app can publish `readDocument`\n\nand `replaceSelection`\n\n. A shop can publish `searchProducts`\n\nand `addToCart`\n\n. The tool runs inside the page, where the product already knows how its own data and controls work.\n\nThat is the right input to AgentPort. AgentPort does not ask developers to rewrite WebMCP in a private format. It collects the tools a page registers through `document.modelContext`\n\nand lends them to the user's agent for the session.\n\nWebMCP and AgentPort solve different parts of the problem:\n\n- WebMCP says what the website can do.\n- AgentPort says which user-owned agent may do it, with whose consent, for how long, and over which private connection.\n\nWebMCP does not choose the user's agent. It does not prove that the agent belongs to the user, connect to an agent on a laptop or VPS, or set the bounds of a session. AgentPort adds that missing trust and transport layer.\n\nThe full path is simple: **WebMCP tools in, the user's agent in the middle, and streamed results back to the app.**\n\n## The parts exist. The composition does not\n\nAgentPort did not invent tool descriptions, agent event streams, browser-held keys, consent choosers, or fine-grained grants. The design makes more sense when those sources are treated as constraints instead of competitors. The project's [prior-art review](https://github.com/gkoreli/agentport/blob/main/docs/reviews/prior-art-synthesis.md) traces six related fields; these are the references that bear most directly on the product claim.\n\n| Prior art | What it already solves | What remains outside its boundary |\n|---|---|---|\n|\n\n[AG-UI](https://docs.copilotkit.ai/ag-ui/introduction)and[ACP](https://github.com/agentclientprotocol/agent-client-protocol/blob/main/docs/protocol/v2/overview.mdx)[NIP-07](https://nips.nostr.com/7)[WalletConnect Sign](https://github.com/WalletConnect/walletconnect-docs/blob/main/docs/api/sign/wallet-usage.md)and[Network](https://docs.walletconnect.network/network)[Credential Management](https://w3c.github.io/webappsec-credential-management/)[OAuth Rich Authorization Requests](https://www.rfc-editor.org/rfc/rfc9396.html)These sources do not prove that AgentPort's implementation is secure. They show that separate fields reached the same design pressure: keep keys out of the requesting page, put consent in trusted UI, describe authority as data, and bind it to a limited target.\n\nThe narrower novelty claim survives that comparison. AgentPort joins a **user-chosen remote agent** to an **application-defined capability surface** through a **user-held, scoped, revocable grant**, while a blind relay carries the **end-to-end encrypted session**. I have found each phrase elsewhere. I have not found the full sentence elsewhere.\n\n## The web is the first surface, not the boundary\n\nThe current public integration starts in a browser. That is why AgentPort has `connect.js`\n\n, a wallet extension, a hosted wallet, and WebMCP support. It is the shortest path to proving that an application can borrow an agent without owning it.\n\nThe protocol underneath does not attach an agent to “a website.” It attaches an agent to a **surface**: a named application context with a route, a capability grant, an expiry, and a place where consent can be judged.\n\nThat distinction now runs through the code:\n\n- the wire connects a generic client surface to an agent daemon through a relay;\n- the client can identify a non-browser application as\n`app://local`\n\n; - the AG-UI adapter turns an AgentPort session into events that existing agent interfaces can render;\n- ACP lets the daemon drive Claude Code, Codex, Goose, or another compatible runtime;\n- the authority layer decides what an attachment may do without depending on one browser widget.\n\nWebMCP is one capability adapter. It is the right adapter for websites because the page can publish its own tools. A desktop app, IDE, terminal UI, or another client can lend a different set of functions through the same attachment model.\n\nThe browser is the supported public integration today. The other client surfaces are a direction already exposed by the protocol and libraries, not a claim that finished integrations ship for each one. The goal is one agent across every application surface, with the same ownership, consent, grant, and encrypted-session rules.\n\n## One script connects the web\n\nAn app developer starts with one script element:\n\n```\n\n```\n\nThe page can then register an ordinary WebMCP tool:\n\n```\nawait document.modelContext.registerTool({\n name: 'inkwell.document.read',\n description: 'Read the current document',\n inputSchema: { type: 'object', properties: {} },\n execute: () => ({ text: editor.value }),\n});\n\ndocument.querySelector('#connect-agent').addEventListener('click', async () => {\n const session = await AgentPort.connect({ name: 'Inkwell', tools: [] });\n await session.prompt('Tighten the opening paragraph.');\n});\n```\n\nAgentPort collects that registration when the user connects. The call starts from a user gesture so the browser can open the wallet. A site can also pass tools straight to `AgentPort.connect`\n\n, but WebMCP is the path that lets the same site tools work with more than one agent system.\n\nThe site does not need an AI provider, an API key, a model picker, or an inference bill. It publishes what its product can do and lets the user choose the agent.\n\nThe script alone cannot know what “send invoice” or “publish article” means inside every product. The app must expose those actions. This is a good limit: the app defines what can happen, while the user decides who does it.\n\nWebMCP remains an experimental draft, so the current claim must stay narrow. AgentPort supports imperative tools registered after its script loads, including the older `navigator.modelContext`\n\nform. It does not claim full WebMCP support. Today, every tool collected from a page asks for user approval on each call because the page cannot grant authority to itself.\n\n## The WalletConnect mental model\n\nIf you know crypto wallets, WalletConnect is the useful mental model. [Trust Wallet](https://developer.trustwallet.com/developer/develop-for-trust/mobile) is one wallet product that accepts WalletConnect sessions. WalletConnect is the connection layer: a dapp proposes chains, methods, and events; the wallet shows the request; the user approves or rejects it; and the settled session has an expiry and a disconnect path. Its network relay carries end-to-end encrypted messages without reading them.\n\nThe mapping is close:\n\n| WalletConnect | AgentPort |\n|---|---|\n| dapp session proposal | application attachment request |\n| wallet and selected accounts | user wallet and selected agent |\n| approved chains and methods | approved application capabilities |\n| session topic and expiry | attachment identity and expiry |\n| encrypted relay | encrypted relay |\n| session disconnect | teardown or revocation |\n\n\"AgentPort is WalletConnect-shaped infrastructure for user-owned agents, with one crucial reversal: the application lends capabilities to the agent.\"\n\nIn WalletConnect, the dapp asks to use capabilities held by the wallet, such as signing or sending a transaction. In AgentPort, the application offers capabilities it holds, such as reading the open document or updating a task, to the agent the user chose.\n\nThe other limit is that an agent is more than a key holder. It has a runtime, model, memory, prompts, private tools, a streaming conversation, and work in progress. Calling AgentPort “Trust Wallet for agents” would make it sound like one agent app. Trust Wallet is closer to one possible wallet implementation at the edge of AgentPort. WalletConnect better captures the pairing and trust shape, while AgentPort's north star remains one agent across every application surface.\n\n[NIP-07's `window.nostr`](https://nips.nostr.com/7) supplies a second useful piece: the page asks a browser-held signer to act without receiving its secret key. AgentPort applies that custody split to agent ownership and session consent.\n\nA site asks to connect. The user picks one of their agents and approves the actions the site wants to lend it. The agent may run on the user's laptop, a home server, or a VPS. The site does not need to know which runtime or model sits behind it.\n\nThe user keeps control of:\n\n- the agent and where it runs;\n- the model and the bill;\n- its memory, prompts, files, and private tools;\n- which site actions it may use, and for how long.\n\nThe website learns only what it needs for the session: that an agent connected and what happened through the actions the site supplied. It does not receive the user's model key, private memory, other tools, or past chats.\n\n## Private by design\n\nThe agent can run anywhere because the session content is encrypted from end to end. AgentPort's relay pairs the browser with the agent and passes sealed messages between them. It carries ciphertext; it cannot read the conversation.\n\nThe relay also stores no session history. Durable identity stays at the edges, with the user's wallet and agent. Secret keys never cross the wire.\n\nThis needs one precise caveat. End-to-end encryption protects the connection from the relay and other middlemen. It does not make an app blind to data that the user or agent chooses to send through that app's own actions. If an agent replaces text in an editor, the editor can see the new text. Privacy comes from a narrow grant, clear consent, encryption in transit, and keeping the agent's wider context out of the site.\n\nPrompts and transcripts belong with the agent, under the user's control. AgentPort is not an inference router and does not become another company that collects the user's chats.\n\nIf you do not want to trust the hosted relay even with ciphertext, you can run your own.\n\n## The tenets\n\nAgentPort can change its transport, wallet, runtime adapters, and user interface. It cannot trade away these rules without becoming a different product:\n\n**The user owns the agent.** AgentPort never chooses the model, keeps the transcript, or sits on the inference path.**The application owns its capabilities.** It decides what the attached agent can read or change. The agent does not inherit the rest of the product.**Consent stays with the user's key.** A page cannot approve its own request. The wallet or daemon shows the decision and signs the grant.**Every attachment has bounds.** A grant names one agent, one surface, a set of actions, and an expiry. Both ends enforce it, and the user can revoke it.**The middle stays blind.** Session content is sealed between the application surface and the agent. The relay moves ciphertext and stores no chat history.**The connection stays small.** One call should attach an agent. AgentPort consumes WebMCP, ACP, AG-UI, and MCP instead of replacing them.\n\nThese are not feature preferences. They are the test for every feature. An inference proxy would break the first rule. Consent drawn by the page would break the third. A broad, permanent tool grant would break the fourth.\n\n## Stop rebuilding the same chatbot\n\nToday, app teams keep building chat panels, model menus, prompt stores, rate limits, billing systems, and tool loops. Then they charge users to fund the same parts every other app also built.\n\nWith a user-owned agent, an app can focus on its real value. A writing app should build a fine editor. A task app should build a fine way to plan work. Both can expose useful actions to the same agent.\n\nThe user gets continuity. The agent that helped research an idea can edit the draft and create the follow-up tasks without becoming three separate bots. Its memory and working style do not reset at each domain.\n\nThe developer gets a smaller product. There is no model contract to pick, no inference cost to hide inside a paid tier, and no need to hold the user's AI credentials.\n\n## It should work everywhere\n\nSites that publish WebMCP tools give AgentPort clear, named actions with tight grants. That gives the agent the safest and most useful view of the product. A site can add the AgentPort script to offer its users a direct connection, while the extension can collect the same WebMCP tools on sites that did not add AgentPort itself.\n\nSites that do not add it can still work through a browser extension that lends common page actions such as reading, filling, clicking, and scrolling. Native actions remain better because they carry the site's intent, but users should not have to wait for every site to opt in.\n\nIn both cases, the important part stays the same: it is the user's agent. A browser vendor does not replace it with another assistant. A website does not rent the user a fresh bot. The agent they already chose gains limited access to the page in front of them.\n\nThe browser proves the model, but it should not own the model. The same agent should attach to a desktop editor, an IDE, a terminal application, or a product surface that has no DOM and no WebMCP. Each application lends only its own capabilities. AgentPort carries the identity, attachment, consent, and private session between them.\n\n## The north star: one agent everywhere\n\n\"A person should own one agent and carry it everywhere.\"\n\nSoftware subscriptions will not vanish, nor should they. People should pay for products that help them. But access to an AI model should not become a separate $20 toll inside every product.\n\nLet users pay once for the agent they want. Let them run it where they want. Let each application lend it only the capabilities needed for the task.\n\nFor developers, the front door starts here:\n\n```\n\n```\n\nFor users, the promise is even shorter:\n\n\"Your agent. Your subscription. Your data. Every app.\"\n\nThe core path works now: WebMCP tool collection, pairing, ownership checks, scoped grants, streaming, tool calls, approvals, and teardown. Under the hood, ACP lets the daemon drive different agent runtimes, while AG-UI-shaped events carry the output. AgentPort sits between those parts as the trust and transport layer they do not provide.\n\nThe long-term goal is bigger than one web integration. Websites should publish capabilities through WebMCP. Other applications should expose the capabilities native to their surface. Users should bring the agent that uses them.\n\nOne agent should move through all of them.\n\nThe end state is not a larger AgentPort service. It is a common application primitive. A user attaches the same agent to two unrelated products and thinks nothing of it. Then browser and operating-system teams argue that this belongs in the platform, and the project no longer needs to explain why it exists.\n\n## Glossary\n\n| Cross-reference | What the source establishes | Why it matters to AgentPort | Date |\n|---|---|---|---|\n|\n\n[Composio](https://docs.composio.dev/docs)[WebMCP](https://webmachinelearning.github.io/webmcp/)[AG-UI](https://docs.copilotkit.ai/ag-ui/introduction)and[ACP](https://github.com/agentclientprotocol/agent-client-protocol/blob/main/docs/protocol/v2/overview.mdx)[NIP-07](https://nips.nostr.com/7)`navigator.agent`\n\n: the requester asks, while the user's trusted component holds the key.", "url": "https://wpnews.pro/news/bring-your-own-ai-agent-everywhere", "canonical_source": "https://gkoreli.com/bring-your-own-ai-agent", "published_at": "2026-08-20 00:00:00+00:00", "updated_at": "2026-09-03 06:53:28.818553+00:00", "lang": "en", "topics": ["ai-agents", "ai-products", "ai-tools"], "entities": ["AgentPort", "Composio", "Brave Leo"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/bring-your-own-ai-agent-everywhere", "markdown": "https://wpnews.pro/news/bring-your-own-ai-agent-everywhere.md", "text": "https://wpnews.pro/news/bring-your-own-ai-agent-everywhere.txt", "jsonld": "https://wpnews.pro/news/bring-your-own-ai-agent-everywhere.jsonld"}}