Relay: How We Built a Home for Agent-Created Work Georgian, a private equity firm, has built Relay, an internal platform that lets AI agents publish Markdown and HTML artifacts to a secure, shareable home. The tool addresses the 'last mile' problem of sharing AI-generated work, offering versioning, inline commenting, and SSO while avoiding vendor lock-in and keeping data on their own infrastructure. Relay is now used across Georgian's teams for dashboards and reports. Generative AI has made us more productive https://www.science.org/doi/10.1126/science.adh2586 than ever https://doi.org/10.2139/ssrn.4945566 , 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 https://www.hbs.edu/faculty/Pages/item.aspx?num=64700 . 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 https://claude.com/blog/using-claude-code-the-unreasonable-effectiveness-of-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 https://support.claude.com/en/articles/9487310-what-are-artifacts-and-how-do-i-use-them and ChatGPT Sites https://openai.com/academy/chatgpt-sites/ plug straight into the chat interface, but lock you into proprietary ecosystems. Shopify built Quick https://shopify.engineering/quick , a powerful platform for vibecoded sites on their intranet, but kept it internal. Display.dev https://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 . Enabling our most agent-forward workflows 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. A peek under the hood Relay’s architecture prioritizes simplicity and defense in depth. At its core is a FastAPI server that exposes three interfaces: 1. a server-rendered library UI where human users browse and manage their artifacts; 2. a Model Context Protocol https://modelcontextprotocol.io/docs/2026-07-28/getting-started/intro MCP endpoint and a REST API endpoint through which agents publish and list them; and 3. a set of serving routes that deliver the artifacts themselves. Every endpoint is gated by an auth layer in which Clerk 1 footnote-1 authenticates humans and agents acting on their behalf, while static API keys authenticate programmatic callers. Relay is served as a Render web service https://render.com/docs/web-services 2 footnote-2 , with metadata stored on Render Postgres https://render.com/docs/postgresql . 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 loaders, 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 Island https://www.island.io/ 3 footnote-3 , 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 loading, 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 ’ blocks fetch , 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 see clickjacking https://en.wikipedia.org/wiki/Clickjacking ; - base-uri ‘none’ prevents a