Generative AI has made us more productive than ever, yet sharing what we create with it remains stubbornly impractical. Remember drafting something in ten minutes, only to spend twenty more figuring out how to get it in front of your colleagues? We do. When powerful LLMs botch simple tasks, researchers chalk it up to their “jagged” capability frontier. But the more work we’ve run through AI, the clearer it’s become that the jaggedness doesn’t stop at the models. It extends to the tools and workflows around them. Today, we’re focusing on this last mile problem in AI-native work and showing how we solved it for ourselves.
Agents do their best work in Markdown and HTML. Markdown is token-efficient. HTML can be beautiful and interactive. Together Markdown and HTML give readers filterable tables, embedded charts, and responsive layouts to explore information rather than just view it. Nevertheless, a format that’s easy to produce or pleasant to read can still be awkward to share.
At Georgian, the friction was palpable. Earlier this year, we launched Agentify, a firm-wide initiative to implement AI agents and tools across our operations. Our teams moved quickly, using LLMs to build automated dashboards replacing clunky spreadsheets and mocking up diagrams that previously wouldn’t have justified the manual effort. But sharing was a stumbling block from the start. Users were screenshotting Claude outputs for Slack, pasting Markdown into Google Docs, and trading tips on how to view HTML files. What we needed was the immediacy of Slack and the durability of a doc, with Markdown and HTML as first-class formats.
We searched for off-the-shelf solutions, but every option came with compromises. Claude Artifacts and ChatGPT Sites plug straight into the chat interface, but lock you into proprietary ecosystems. Shopify built Quick, a powerful platform for vibecoded sites on their intranet, but kept it internal. Display.dev was the closest fit, letting agents publish via MCP to a stable URL with versioning, inline commenting, and SSO. But it only offers hosting on their infrastructure, which was a dealbreaker for our sensitive data.
That left us at a crossroads. Two principles drove our ultimate decision: avoid vendor lock-in and retain full control of our data. In AI, where the gold standard shifts in weeks, platform commitments are a tax on agility. When a platform falls behind, you get stuck waiting. Without a great option on the market, and with the cost of writing code plummeting, we decided to build one ourselves. We call it Relay.
Relay has become an important part of how Georgian’s teams share and collaborate on AI-assisted work. Some artifacts, like self-updating dashboards and numbers-heavy reports, reduce toil. Others give human judgment a canvas that colleagues can challenge and build on. With Relay, the gap between producing something useful with agents and getting it in front of the right people has shrunk significantly.
Relay’s architecture prioritizes simplicity and defense in depth. At its core is a FastAPI server that exposes three interfaces:
- a server-rendered library UI where human users browse and manage their artifacts;
- a Model Context Protocol (MCP) endpoint and a REST API endpoint through which agents publish and list them; and
- a set of serving routes that deliver the artifacts themselves.
Every endpoint is gated by an auth layer in which Clerk1 authenticates humans and agents acting on their behalf, while static API keys authenticate programmatic callers. Relay is served as a Render web service2, with metadata stored on Render Postgres. Artifacts are stored in object storage buckets.
Relay is designed to serve data quickly and receive data carefully. When users open a Relay link, it’s a matter of a database lookup and quick pull from object storage before the server streams the identified artifact to their browser. Publishing an artifact is more involved by comparison. HTML and SVG files are preserved as-is. Markdown documents and slides are passed to a server-side rendering pipeline that bakes them into rich, brand-compliant HTML. HTML and SVG files bypass the rendering pipeline but still pass through Relay’s publication-time validation. By rendering non-browser-native formats server-side, Relay keeps its read path free of front-end s, runtimes, and hydration steps. The rendering pipeline also strips out potentially unsafe dependencies on external content.
That brings us to Relay’s security model. As an investor, Georgian is legally and ethically obligated to protect the sensitive data under its control. To that end, Relay is built with security as a priority.
Relay’s first line of defense is identity. Every request — whether from a human in Island3, an agent in Claude Desktop, or a scheduled job — must resolve to a verified identity before Relay takes any action. Humans authenticate through Clerk, with Relay acting as a standard OAuth client without the use of any third-party JavaScript or cookies. Agents acting on a user’s behalf inherit those same credentials through MCP’s built-in OAuth flow, while programmatic callers authenticate with API keys against a dedicated REST endpoint. Where a proven tool exists, we delegate to it. Clerk operates Relay’s auth boundary and our cloud providers guarantee the encryption of Relay’s artifacts and metadata at rest.
Relay is also structured for defense in depth. Our auth boundary keeps strangers out, but what if an account is compromised? What if an agent, drafting on the basis of scraped Internet sources, publishes an artifact with a stowaway malicious script? For these eventualities, Relay sandboxes every artifact it serves with a browser-enforced Content-Security-Policy (CSP) header:
default-src ‘none’;
script-src ‘self’ ‘unsafe-inline’;
style-src ‘self’ ‘unsafe-inline’;
img-src ‘self’ data:;
font-src ‘self’ data:;
connect-src ‘none’;
form-action ‘none’;
frame-ancestors ‘none’;
base-uri ‘none’;
sandbox allow-scripts allow-same-origin;
default-src ‘none’ starts by blocking all resource , then we carve out explicit exceptions for the resources we do in fact want to load. Scripts, styles, images, and fonts are allowed if they’re embedded in the document or served elsewhere by Relay. Next, we layer in blocks to close a variety of exfiltration paths:
-
connect-src ‘none’ blocksfetch,XHR, and WebSocket requests; -
form-action ‘none’prevents form-based redirects (redirection can be a nifty way to smuggle data in a URL like‘https://evil.com/steal?data=tylers-diary’); -
frame-ancestors ‘none’blocks other sites from embedding the artifact in an iframe (seeclickjacking ); -
base-uri ‘none’prevents a <base> tag from rewriting relative URLs to point at an external server; and -
sandbox allow-scripts allow-same-originforbids top-level navigation and popups.
The net effect is that a Relay artifact can run JavaScript to render interactive charts, animate SVGs, and handle button clicks, while browser-enforced controls sharply limit its ability to contact external services or exfiltrate data.
Relay was designed to prioritize some goals over others, which entailed some choices for its early versions.
MCP over CLI. The main ways to connect agents to a remote service like Relay are MCP servers, which expose tools over a network protocol, and CLI wrappers, which shell out to a command-line program. MCP servers are supported in every Claude interface.4 CLIs only work in an environment with a shell and a filesystem — so in Claude Code, to a limited extent in Claude Cowork, and not at all in Claude Chat. Since Relay serves technical and non-technical users alike, it needs to support workflows based out of Cowork and Chat. That alone might have settled our decision, but it wasn’t the only consideration.
CLIs are also harder to operate than MCP servers. A CLI has to be distributed, versioned, and debugged on every machine. That’s a manageable ask for a small team of engineers, but a burden for an org spanning everything from investment to legal. By contrast, a remote MCP server can be deployed just by distributing a URL.
Additionally, MCP clients include features that you would need to implement yourself in a CLI. For example, Claude Desktop comes with all of the plumbing you need to handle an auth flow, from managing the token handoff during login, to caching tokens, to refreshing them. Ultimately, both an MCP client and a CLI would have allowed agents to piggyback on their users’ Clerk sessions, but picking MCP meant less boilerplate code to write and maintain.
Finally, while it’s true that CLIs have gotten attention for being more token-efficient than MCP servers, Relay benefits more from MCP’s advantages in reach, operations, and simplicity than it loses from its deficit in efficiency. Nevertheless, Relay’s MCP server saves input tokens by exposing only a handful of tools and hiding the write-oriented ones from agents that are only allowed to read.
The cost of remote publishing. The operational simplicity of a remote MCP server came with a catch. When an agent publishes an artifact, the entire file — HTML, styles, embedded images and all — must pass through the tool call as a string parameter. This process is painless for a short Markdown document, but stings for richly styled HTML artifacts that can run to tens of thousands of tokens. In the worst case, publishing a file that already exists on disk can take over a minute and burn output tokens on what is, functionally, a file copy.
This wasn’t a surprise. The MCP specification lacks native file transfers, and efforts to fix it have moved slowly. An early proposal (SEP-2356) introduced basic file pickers, but lacked a plan for large payloads. The best current proposal (SEP-2631) sketches a more robust upload path through dedicated endpoints instead of the context window, but it missed the July 2026 release and remains stuck in draft. We shipped anyway, on the theory that user adoption would prove (or disprove) Relay’s concept before file sizes became a pressing issue. In the end, we got the adoption we hoped for and the upload bottlenecks we feared.
So rather than wait for the spec, we’re building our own presigned-URL upload flow. The server issues a short-lived URL pointing directly at cloud storage, and the agent posts the file to it from its own environment, skipping the context window entirely. We expect to ship well before the official standard arrives.
By the time this is published, Relay will already support some of the headline features envisioned in this post’s first draft.
We started with Google Docs-style collaboration. Users can now leave comments in inline threads, with a bot mirroring new comments to Slack DMs. Granular access controls let users choose who can view and edit artifacts. We also added an upload button, giving users a direct way to publish larger files while we finish the agent-facing presigned-URL flow described earlier.
Next, we plan to plug ambient agents into Relay. Today, nearly every Relay artifact starts with a human prompt. We want to flip that default. Picture this: one of my background agents generates a market map every Monday morning and publishes it to Relay. Seconds later, a colleague’s agent picks it up for a couple rounds of review and editing. Then a third agent uses that market map to triage which companies are strong matches for our investment theses. Ultimately, after ten minutes of review, I have an output in hand that used to take multiple hours of back-and-forth iteration. The early pieces are already in place. Some of Georgian’s background agents publish their outputs to Relay today.
Agents aren’t the only publishers we have in mind. An internal security scanner, for example, could publish an interactive findings report to Relay after each scan, instead of requiring its own frontend. As agent chains lengthen and more services plug in, we envision Relay growing into the connective tissue of our most AI-forward workflows.
Tyler Biswurm is an AI Engineer and Researcher in Georgian’s AI Lab. His work focuses on AI safety and security, informed by previous experience as a Site Reliability Engineer and graduate research in AI at the University of Toronto.
Relay was built by Tyler, Jeremy Chua, and Qaid Damji.
Grateful to Ganni Galea Curmi and Aryan Khurana for their thoughtful feedback on this piece.
This blog is provided for informational purposes only and should not be relied upon as legal, business, investment, or tax advice. Nothing in this blog constitutes investment advice, nor is it intended for use by any investors or prospective investors in any Georgian funds. This blog may include links to external websites or information obtained from third-party sources. Georgian has not independently verified and makes no representations regarding the accuracy or completeness of such information, whether current or ongoing. If this content includes third-party advertisements, Georgian has not reviewed such materials and does not endorse any advertising content or the companies referenced.
Any investments or portfolio companies mentioned are for illustrative purposes only and may not be representative of all investments made by funds managed by Georgian. Please contact Georgian for more information.
Clerk is a Georgian Portfolio company. Read more about our investment here: Why Georgian Invested in Clerk
Render is a Georgian Portfolio company. Read more about our investment here: Why Georgian Invested in Render
Island is a Georgian Portfolio company. Read more about our investment here: Why Georgian Invested in Island (Again)
The same is true for ChatGPT and Gemini, though in some cases only in their Enterprise versions.