# Serendipity AI — Full Content

This file inlines every published blog post for easy ingestion by LLMs and
agent crawlers. The site overview lives at /llms.txt.

Site: https://serendipity.ai
Updated: 2026-06-11

## MCP as a Backend for Frontend

- Author: Oliver Farren
- Published: 2026-05-22
- URL: https://serendipity.ai/blog/mcp-as-a-backend-for-frontend/
- Summary: I started as an MCP sceptic. What changed my mind wasn't an argument — it was building something, and recognising a pattern I already knew from web architecture showing up somewhere I hadn't expected it.

# MCP as a Backend for Frontend

When MCP landed in November 2024 I read the announcement a few times, blinked, and filed it under this month's AI flavour.

Scepticism about new AI tooling was a reasonable default by then. The previous few years had produced a graveyard of frameworks and abstractions that promised to make building AI systems easier and mostly made them harder to understand. We had been building agents ourselves and had made a conscious decision to move away from the heavyweight frameworks — LangChain, LlamaIndex — in favour of writing closer to the primitives. Yet another protocol? No thanks.

My specific objection to MCP in particular was this. We had been adopting FastAPI across our services. We came for the framework — a well-designed ASGI framework with Pydantic validation at the interface and a clean developer experience — but stayed for the side effects. FastAPI produced rich API documentation almost automatically: interactive, explorable, and available as a machine-readable OpenAPI specification. Our frontend developers loved it. Onboarding onto a new service went from a back-and-forth about what parameters existed to just reading the docs.

So when MCP arrived and described itself as a standard way for agents to discover and use tools, my first thought was: we already have that. It's called an OpenAPI spec. The examples in the announcement felt abstract. The use cases felt contrived. And anyway, if a model is capable enough to do useful work, shouldn't it be able to discover the API endpoints itself, read the documentation, and figure out how to call it? The intelligence is in the model. The interface is already there. What exactly is the problem being solved here?

That position held for a while, and it wasn't entirely wrong. But now in May 2026 I'm beginning to see what all the fuss was about.

---

There's a pattern in web architecture called the Backend for Frontend, or BFF, that's worth understanding here.

The problem it solves is straightforward. You have an API. It's well-designed, stable, and serves your data faithfully. Then you get a mobile client. The mobile client doesn't want the same payload as the desktop — it has less screen space, tighter bandwidth constraints, different interaction patterns. You could add query parameters to let clients specify what they want. You could version the API. Or you could introduce a thin layer that sits between the client and the underlying services, shaped specifically for that consumer's needs. That's the BFF. It doesn't replace the API. It translates it.

The pattern exists because different consumers have genuinely different needs, and a good API shouldn't have to care about all of them simultaneously. The BFF takes on that responsibility instead — shaping responses, aggregating calls, stripping fields the client will never use. The underlying services stay clean. The consumer gets exactly what it needs.

I'll be honest: we never had much appetite for it. Our frontend developers were enthusiastic — a BFF would have given them exactly the interface shape they wanted. The problem was that building and maintaining it would have fallen on the backend team, which at various points also covered infrastructure, AI pipelines, and whatever else needed doing. Good APIs with good documentation got us most of the way there. The BFF always felt like it would double the maintenance surface for the people least asking for it.

What I hadn't accounted for was that agents would constitute an entirely new class of consumer — one the BFF pattern describes almost exactly.

---

The thing that eventually shifted the frame wasn't an argument or a conference talk. I was looking at a search endpoint.

We had a low-level internal endpoint that accepted a query language directly — expressive, powerful, and deliberately not something you'd expose publicly. It's not as catastrophic as exposing raw SQL, you're not going to drop a database, but it's the same category of mistake: your internal implementation becoming someone else's interface problem. The query language was complex enough that even frontier models with access to the full index specification would occasionally get it wrong — malformed aggregations, incorrect field references, queries that ran but returned nonsense. And if a capable model struggled with it, a cheaper one had no chance. The expressiveness that made it useful internally was exactly what made it unsuitable as an agent interface.

So I built a tool over it: a keyword search tool that accepted plain parameters — phrases, keywords, date ranges, sort order — and handled the query construction internally. Then I added a report generation tool, built on the same engine behind [markdown2pdf.ai](https://www.serendipityai.co.uk/blog/markdown2pdf-markdown-pdf-conversion-for-ai-agents), and watched an agent work through a research task and produce a PDF at the end of it, unprompted.

What struck me wasn't the output. It was how fluently the agent had moved through the tools — no fumbled parameters, no wasted calls probing the interface to understand it. The design decisions baked into the tool were guiding the agent's reasoning before it made a single call: which parameters to expose, which to absorb internally, how to describe the difference between a phrase and a keyword in terms the model could reason over rather than just execute against.

That's what a BFF does. It translates between what the underlying system offers and what a specific consumer actually needs. I'd just built one for an agent without meaning to.

---

There's a temptation, once you've accepted that agents need their own interface layer, to treat it as a purely mechanical problem. Define your inputs, document your outputs, make sure the types are right. That's how you'd approach an API for a human developer and it mostly works.

It doesn't quite work for agents, because the interface isn't just a contract. It's a prompt.

When an agent encounters a tool, it reads the description and uses it to reason about whether and how to use that tool. The description shapes what queries it constructs, which tools it reaches for first, how it interprets the results. A poorly written description doesn't just cause confusion — it causes confident wrongness. The agent doesn't know it's misreading the interface.

We found this out the hard way with something as simple as the word "articles." Our corpus contains institutional publications, policy briefings, think tank research, academic outputs — Bank of England working papers, Nature, that sort of thing. We'd been describing it as articles because that's roughly what they are. The agent accepted this, formed a mental model around news media, and would occasionally betray a kind of surprise in its chain of thought when it surfaced something that didn't fit. It wasn't broken, but it was operating with a miscalibrated expectation we had handed it. The fix was a few sentences of honest description of what the corpus actually contained. The agent's behaviour changed noticeably.

The same dynamic runs through individual parameters. Our keyword search tool has a `slop` parameter that controls how strictly phrases are matched — whether "critical minerals" would also catch "critical earth minerals" where a word has crept in between. Describing this in technical terms is accurate and useless. Describing it as "0 = exact phrase order required, 2 = up to 2 intervening words allowed" gives the agent something it can reason over at the point of use.

The same principle applies throughout. The distinction between `must_keywords` and `any_keywords` is described in terms of AND and OR logic. The `publishers` parameter includes an explicit instruction never to put publisher names in the keyword fields — because without that instruction, an agent will, and the results will be quietly wrong in a way that's hard to diagnose.

None of this is documentation in the traditional sense. It's interface design for a reader with one shot to understand it and no way to ask for clarification.

---

There's a cost to getting this wrong that doesn't exist in traditional API design. When a frontend application calls an endpoint and gets back more data than it needs, it renders what's relevant and discards the rest. The overhead is negligible. When an agent does the same thing, every token in that response is sitting in the context window, and the context window is a shared, finite, and increasingly expensive resource.

We have a concrete version of this problem. Our "article" endpoints return full text — title, publisher, publication date, body, everything. For an API client that's fine. It's great even. You fetch the payload, take what you need, move on. For an agent working through a research task, fetching full articles repeatedly is quietly ruinous. Each response bloats the context. Later steps cost more because the model is now reasoning over a larger window. A seventeen step research run we instrumented came out at over a million input tokens and around two dollars. A meaningful fraction of that was the agent carrying article text it had already processed and no longer needed.

The usual response to context bloat is to push work into a subagent — spin off a cheaper, smaller model to handle retrieval and summarisation, preserve the main context for reasoning. This genuinely helps: a subagent that reads a ten-thousand token article to extract a single link absorbs that cost within its own short context rather than pushing the deadweight through the main agent loop. But it shifts complexity onto the consumer. Implementing sub-agent workflows to compensate for poorly shaped tool responses is a reasonable expectation for a sophisticated internal team. It's a much stronger assumption to make about any agent that might connect to your MCP server. And subagents typically run on smaller models — Haiku rather than Sonnet — which means your tool interface needs to be legible not just to your most capable model but to the cheapest one in your stack. Designing for the smaller model turns out to be a useful forcing function. If your tool descriptions are clear enough for a lightweight model to use correctly, they're probably well designed.

Inadvertently exhausting an agent's token budget through generous API responses probably deserves a place on someone's LLM security list. Unbounded consumption via poorly designed tooling.

The fix we're working toward borrows an idea from GraphQL. If an agent only needs the title and a link from an "article", the tool should be able to return just that. The underlying API doesn't need to change. The tool layer absorbs the responsibility, the agent gets a leaner response, and the context window stays manageable.

This is the BFF pattern doing its most concrete work.

---

One of the more useful things we built during this process was an introspection tool. It connects to the MCP server, reads the tool schemas cold, and asks a model to describe what each tool is for, when to use it, and what its pitfalls are. No additional context. Just the descriptions we'd written.

The output is a legibility test. If the model can correctly articulate the routing logic — use semantic search for broad conceptual queries, keyword search when you have specific entities, discovery before retrieval — then the descriptions are doing their job. If it can't, or gets something subtly wrong, you have a design problem that will show up later in production in ways that are much harder to diagnose.

It doesn't catch everything. A well-designed interface can still be let down by a poorly designed one sitting adjacent to it. We use the Slack MCP for some internal tooling, and at one point asked it to summarise messages from the last twenty-five days. It came back with a confident, well-formatted summary. Wrong year. The interesting question is where the failure actually lived. If Slack's MCP navigates by timestamp rather than something more natural like a `days_back` parameter, then the interface itself is part of the problem — the agent has to reason about timestamps correctly before it can even form a valid query. Which is exactly the kind of complexity a well-designed tool should absorb internally rather than expose upward.

This connects to something worth naming directly. A lot of teams shipping MCP servers are, understandably, generating them automatically from their OpenAPI specs. Export the swagger JSON, wrap it in a server, done. It's also, perhaps, motivated by something other than a considered view on agent experience — shipping MCP has become a signal in its own right, and auto-generating from swagger is the path of least resistance to being able to say you've done it. The quality of the experience that produces is largely the consumer's problem. The problem is that an OpenAPI spec is designed for a human developer who can try things, ask questions, have their AI assistant write the unit tests, and iterate their way to a working integration — even against a poorly documented API, there's a feedback loop. And that's before you get to ontological fuzziness, where the schema is accurate but the underlying model clashes with what the interface implies. Take AWS S3 as an example. It's a flat key-value store with no native concept of directories — just buckets and keys. The console presents the illusion of a folder hierarchy. The API quietly doesn't have one. A developer encounters this mismatch, works through it, tries a few things, and gets there eventually through trial, error, and shared confusion. An agent encountering this for the first time — which is every session, for every new interface — reads the schema, forms a model of reality from it, and proceeds on wrong assumptions with no mechanism to correct them. Feeding a spec to an agent gives it a second-class experience: complex interfaces, no guidance on sequencing, no absorption of internal complexity. The BFF exists precisely because "just use the underlying API" was never the right answer for demanding consumers. Auto-generated MCP is the same mistake, one layer up.

These failures point at something that doesn't have a clean name yet in how we talk about MCP design. It's not quite usability, which implies a human user. It's not just prompt engineering, which implies a one-off interaction. It's something more like the accumulated quality of the experience an agent has when it encounters your tools — the friction or fluency at the point of reasoning, not just at the point of execution. We've started calling it Agent Experience, for want of a better term.

Tools are the interface. Agent Experience is the measure of how well an agent can actually use them.

---

There's a broader shift happening alongside all of this that's worth naming.

For most of the past two years, building a useful agent meant a non-trivial engineering project: choose a framework, design the tool interfaces, wire up the orchestration, handle retries and context management, test the whole thing end to end. The knowledge of how to do that well was locked up in the implementation. MCP starts to change this by moving tool maintenance to the server layer — the tools live on the server, any capable agent can discover and use them. What's emerging alongside it is a class of agent harnesses that handle the orchestration side: give them a prompt and a set of MCP servers and they'll run a multi-step research task, reflect on their own tool usage, and produce a structured output.

The practical consequence is that the interface contract is now with the agent class, not with a specific client. We built our MCP server for internal use — our own agents, our own harnesses, engineers on the team experimenting with research workflows. But there's very little separating that from a public-facing server. The same tool descriptions that guide our internal agents will guide any agent pointed at the server. The same design decisions that make the tools legible internally make them legible externally.

This is something we didn't get for free with our APIs, however good the documentation was. An OpenAPI spec is written for a developer who will read it once, build something durable, and move on. An agent reads the interface fresh every session, reasons from it immediately, and carries no memory of previous mistakes. The interface has to work first time, every time. That constraint turns out to be a useful forcing function for writing better descriptions than you'd otherwise bother with.

---

MCP will evolve, or be succeeded by something solving the same problem. The protocol is young, the tooling is still maturing, and the current landscape of clients and servers will look different in a year. That's fine. Protocols come and go.

The pattern underneath it is more durable. Every time you introduce a new class of consumer — mobile clients, third-party integrators, internal services with different latency requirements — you eventually discover that your existing interfaces weren't designed for them. The response shapes are wrong. The abstractions leak. The documentation that worked for one audience confuses another. The BFF pattern exists because this is a recurring problem with a recurring solution: a layer that translates between what your system offers and what a specific consumer needs.

Agents are a new class of consumer. They read interfaces literally, reason from descriptions immediately, carry no session memory, and operate under hard token constraints that make response bloat genuinely expensive. They need interfaces designed for them, not adapted from interfaces designed for humans. MCP is currently the most coherent attempt to standardise what that looks like.

What we don't yet have is a rigorous way to measure how well we're doing it. We can run an introspection agent and check whether the descriptions are legible. We can instrument a research run and watch where the token cost goes. We can ask an agent to reflect on its own tool usage and surface the gaps. We can write evals that test whether a tool produces the right output given a representative set of inputs — and that class of solution is maturing fast. But evals measure output quality after the fact. Agent Experience is a design-time concern: the quality of the interface before the agent ever runs. These are related problems with different solutions, and the second one is less well understood.

We've started calling it Agent Experience. It sits alongside Developer Experience as a design concern in its own right: not the schema, not the response format, but the cognitive fluency the interface produces at the point of reasoning. Getting it right is, at the moment, more craft than science. That will probably change.

In the meantime, the most useful reframe we found was the simplest one. Stop thinking about MCP as an API replacement. Start thinking about it as a Backend for Frontend where the client is an agent. The rest follows from there.

---

## The AI Productivity Paradox: Why Your Agents Should Be Run Like Mini-Startups

- Author: Jim Marshall
- Published: 2025-12-15
- URL: https://serendipity.ai/blog/ai-productivity-paradox/
- Summary: The 'show me the money' phase of AI has arrived. The problem isn't that agents can't deliver value — it's that we measure it badly. A case for running every agent like a mini-startup with its own P&L.

The "AI Gold Rush" is in full swing, but the pickaxes are getting expensive. Lately, the conversation has shifted from breathless excitement to skepticism. Is there an AI bubble? Are we simply throwing billions at a technology that isn't delivering the promised productivity boom?

Reputable firms are asking hard questions. Sequoia Capital famously posed the "$600 Billion Question," asking where the revenue is to justify the massive infrastructure build-out. Goldman Sachs has released reports questioning whether the returns on AI will ever match the exorbitant costs. The consensus is shifting: we have moved past the "wow" phase and entered the "show me the money" phase.

The concern is valid. While almost every organization is experimenting with AI agents, the landscape is immature. We see demos that dazzle but deployments that fizzle. Our thesis is that the problem isn't necessarily that AI can't deliver value — it's that we are not measuring it very well.

## The Measurement Gap

Currently, the ecosystem is flooded with "agent instrumentation" frameworks. They are great at what they do: tracing execution paths, monitoring latency, debugging prompt chains, and catching hallucinations. They answer the engineering question: "Is the agent working?"

But they fail to answer the business question: "Is the agent worth it?"

We are flying blind on the unit economics of AI. We deploy agents that might save a junior employee 10 minutes of work, but if that agent costs $100 in compute and API calls to run, we are burning cash on every transaction. Without visibility into this ratio, companies are understandably hesitant to scale their pilots into production.

## The "Mini-Startup" Mental Model

To solve this, we need to stop treating AI agents like software features and start treating them like employees — or better yet, like mini-startups.

Every startup has a burn rate and a revenue model. Your AI agents should have the same. To truly understand the return on investment of an agent, we need a framework that instruments and reports on two distinct categories in real-time:

- **Cost Drivers:** We need granular tracking of every cent an agent spends. This includes the obvious LLM token costs, but also the "hidden" costs: third-party API transaction fees, storage costs, and the amortized "salary" of the development team and subject matter experts who built and maintain it.
- **Value Drivers:** On the flip side, we must quantify the output. This isn't just "task complete." It is the dollar value of time saved, the cost of human effort deflected, or the direct revenue attributed to an upsell.

When you instrument these two flows, you unlock the ability to see an agent's P&L (Profit and Loss) statement.

## The Break-Even Point

Once you view an agent through this lens, the "productivity paradox" begins to resolve itself. You can calculate the break-even point — the exact moment an agent covers its development costs and starts generating net profit for the business. You can see the payback period for your investment.

This framework transforms AI strategy from a guessing game into a portfolio management exercise. You can look at your fleet of agents in aggregate:

- **The Stars:** Agents with high margins and quick payback periods? Double down investment.
- **The Zombies:** Agents that burn more cash than the value they create? Cull them immediately.

This level of financial clarity is the missing link between "cool tech demo" and "sustainable competitive advantage."

## Bridging the Gap

The industry needs a solution for this kind of financial instrumentation — a way to report on the business viability of our digital workforce.

At Serendipity AI, we are developing a framework which tracks the return on investment of AI agents, or rather the "Return On Agent" as we call it. We use it ourselves to track the ROA of the agents we have running in production. It provides an instrumentation and reporting layer focused purely on the cost-value equation, helping organizations finally answer the question of whether their AI investment is paying off. If you are interested in learning more, please [reach out](/contact).

---

## Mosaic Started It. Agents Will Finish It.

- Author: Jim Marshall
- Published: 2025-09-10
- URL: https://serendipity.ai/blog/mosaic-started-it-agents-will-finish-it/
Full article: https://medium.com/@jimmarshall87/mosaic-started-it-agents-will-finish-it-28e6b71d0fb0 (Medium)
- Summary: Why the age of browsers is ending, and what's taking its place. The internet of documents gave way to the internet of applications — which is now yielding to the internet of agents, with rich MCP clients as the new browser.

# Mosaic Started It. Agents Will Finish It.

*Why the age of browsers is ending, and what's taking its place.*

In 1993, a small group of developers at the University of Illinois released a curious new piece of software: Mosaic, the first widely used web browser. It could display text and images on the same page — a novelty at the time — and it introduced millions to a new kind of digital experience: the World Wide Web.

Mosaic wasn't flashy. Pages loaded slowly. Links were blue, underlined. Interfaces were sparse and static. But it was a revelation.

What's surprising isn't how far we've come since then — it's how much has stayed the same.

Thirty years later, we still open a browser, type a URL or search query, and view HTML rendered into a page. We still click links, fill out forms, and scroll through documents. The underlying interaction model — document-based, input-driven, screen-bound — has barely evolved.

Yes, we've added speed, polish, and mobile responsiveness. We've stacked a leaning tower of JavaScript frameworks on top — React, Angular, Vue, Svelte — all designed to bend the browser into something it was never meant to be: an application runtime. And to some extent, it works.

But at its core, the browser is still doing what Mosaic did: rendering markup into documents. The interface hasn't caught up with the intelligence behind it.

That's about to shift.

## The Silent Evolution

The internet as we know it — navigated through browsers, powered by search engines, connected by APIs — is being quietly dismantled and rebuilt beneath our fingertips. This transformation isn't just technological; it's architectural.

For decades, web browsers have served a singular purpose: interpret HTML, CSS, and JavaScript to render human-readable interfaces. These technologies weren't designed for complex applications but were stretched and contorted to accommodate increasingly sophisticated needs. We've built workarounds upon workarounds, bending document-centric technologies to serve application-centric purposes.

## Enter MCP and A2A

Recently, a significant development emerged: Model Context Protocol (MCP). This innovation allows applications (MCP clients) to communicate with AI services (MCP servers) in a standardized way, enabling more consistent and powerful AI interactions.

Soon after, Google's A2A (Agent-to-Agent) protocol was released which takes things a step further and enables autonomous agents to communicate with each other directly.

Together, MCP and A2A hint at a much larger architecture shift. But we're still early. Most current implementations focus on primitive text-based exchanges: we type commands, and we get text back. It works, but it hardly feels revolutionary.

This is where we stand today. But there's an obvious next step that no one has taken yet.

## The Missing Piece: Rich MCP Clients as the New Browser

What if MCP clients evolved beyond simple text conduits to become full-fledged interpreters of a new kind of protocol — one specifically designed for human-agent interaction?

Just as web browsers transformed the internet by interpreting HTML to create visual experiences, rich MCP clients could interpret a new kind of semantic markup from AI systems to create intuitive, interactive interfaces on demand.

Imagine a conversation with an AI where:

- Instead of typing "I'm available next Tuesday at 3 PM," a calendar interface appears automatically when scheduling is discussed
- Rather than reading paragraphs describing data, you receive interactive visualizations you can manipulate directly
- Complex decision trees unfold as elegant, tappable options rather than lengthy text explanations

This isn't merely adding buttons to chatbots. It's a fundamental reimagining of human-computer interaction where the interface itself is generated dynamically based on context.

## From Typing to Tapping

Humans prefer to tap, swipe, and click rather than type lengthy commands. Our fingers evolved for manipulation, not just communication. Yet our interactions with the most advanced AI systems still rely primarily on typing. The state of the art is reminiscent of connecting on a 300-baud modem to an online bulletin board system in the late 90's — except you don't even get ANSI colours, just markdown output!

Rich MCP clients would bridge this gap. They would understand when to present a slider for selecting a price range, when to offer a drawing canvas for creative collaboration, or when to display interactive 3D models for spatial concepts — all based on cues from the AI system. An adaptive user interface for the agent economy, if you will.

## The Ripple Effects

This evolution would transform more than just user experience:

1. Developers would design AI experiences rather than static interfaces
2. AI systems would consider not just what to say, but how information should be presented
3. Users would interact with digital systems through natural conversation augmented by intuitive controls

Most importantly, this approach would make agent-driven interfaces accessible to everyone, not just those comfortable with text-based prompting.

## The Blueprint Is Ready

The technical foundation for this transformation already exists. MCP provides the communication framework. Modern browsers have proven that interpretive rendering engines can create rich experiences. AI systems increasingly understand context and intent.

What's missing is the connective tissue — a fabric tailored for agent-human interaction and clients designed to interpret it. The first companies to bridge this gap will define the next era of digital experience.

## The New Internet Taking Shape

This isn't incremental improvement — it's a fundamental rewiring of how we experience the digital world. The internet of documents gave way to the internet of applications, which is now yielding to the internet of agents.

And just as browsers were the gateway to previous iterations, rich MCP clients could be our window into this new world — a world where digital interaction feels less like operating machinery and more like collaborating with an intelligent partner.

The question isn't if this transformation will happen, but who will lead it — and how quickly we'll adapt to a fundamentally different way of experiencing the digital realm.

---

## Introducing markdown2pdf.ai: bridging the agent economy to human productivity

- Author: Jim Marshall
- Published: 2025-06-16
- URL: https://serendipity.ai/blog/markdown2pdf-launch/
- Summary: A service that lets AI agents convert markdown into beautifully formatted PDFs, billed by Bitcoin micropayments. An early bet on agent-native HTTP.

The digital landscape is shifting toward what people are starting to call the
**Agent Economy** — a world in which autonomous software agents collaborate to
complete tasks without a human in the inner loop. At Serendipity AI we're
exploring what infrastructure this future actually needs.

Emerging frameworks and standards are quietly laying the groundwork. **MCP**
and **A2A** describe how agents talk to each other and to tools. Payment
protocols like **L402** (Lightning over HTTP) and **X402** (a revival of the
long-dormant `402 Payment Required` status code) describe how agents pay each
other without humans, credit cards, or onboarding flows in the middle.

## The markdown → PDF gap

Despite the pace of progress, a meaningful gap persists in how AI outputs serve
human needs. LLMs generate **markdown** — a developer-centric format optimised
for software, not for reading. Humans, meanwhile, still prefer **PDFs**:
polished, portable, universal.

Most agentic workflows end with a markdown blob that nobody on the other side
actually wants to read.

## Bridging the gap

[markdown2pdf.ai](https://markdown2pdf.ai) is our first product in this space:
an HTTP endpoint built specifically for agents, that turns markdown into a
beautifully formatted PDF. No accounts. No API keys. No dashboard. The agent
hits the endpoint, gets a `402 Payment Required`, pays a few sats over
Lightning or X402, and receives the PDF.

It's a small product — deliberately. The goal isn't the PDF service itself.
The goal is to learn, at the protocol level, what agent-native HTTP actually
feels like once you remove every assumption that there's a human on the other
end.

For additional details, visit [markdown2pdf.ai/about](https://markdown2pdf.ai/about).

---

## Creating immersive views on visionOS using AI-generated 360° images, SwiftUI and RealityKit

- Author: George Alexiou
- Published: 2024-07-19
- URL: https://serendipity.ai/blog/visionos-immersive-views/
Full article: https://medium.com/@social_93988/creating-immersive-views-on-visionos-by-using-360-images-with-swiftui-and-realitykit-by-serendipity-ai-2907cfafb909 (Medium)
- Summary: How we use AI-generated panoramic imagery and a few RealityKit tricks to deliver immersive Apple Vision Pro experiences without the cost of full 3D scenes.

## Overview

One of the many challenges with creating virtual and augmented reality
applications for visionOS is the cost of 3D content creation. Bespoke 3D
scenes for every part of an application are slow and expensive to produce.
The approach we've taken at Serendipity AI is to reserve full 3D experiences
for a few key moments, and use **360° images plus a small bag of 3D
manipulation tricks** to deliver immersive views everywhere else — convincing
enough that users don't notice the seam.

## Topics covered

In this article we walk through:

1. What an immersive view is and how to design one
2. How to create a realistic immersive view from a 360° image
3. How to modify the approach to load images dynamically via URL

The full write-up — with code, RealityKit setup, and screenshots — lives on
Medium.

---

## Strategic trend forecasting: anticipating the future with artificial intelligence

- Author: Jim Marshall
- Published: 2022-05-23
- URL: https://serendipity.ai/blog/strategic-trend-forecasting/
Full article: https://blogs.lse.ac.uk/businessreview/2022/05/23/strategic-trend-forecasting-anticipating-the-future-with-artificial-intelligence/ (LSE Business Review)
- Summary: If a black swan was only black because we weren't looking for it, what changes when machines can read everything at once?

Nassim Taleb's 2007 bestseller *The Black Swan: The Impact of the Highly
Improbable* set out to help organisations build resilience by preparing
better for rare events. Two decades later, the term has been flattened into
shorthand for any surprising occurrence.

But are these events really unpredictable, or do humans simply lack the
capacity to identify warning signals **at scale**? The thesis of this piece
is that artificial intelligence — capable of ingesting and pattern-matching
across volumes of information no individual or team can absorb — might
excel exactly where people struggle.

If the signals were always there but buried in noise we couldn't process,
then technology that processes noise *as its native medium* should let
organisations and communities anticipate emerging issues before they become
crises. That's the foresight Taleb advocated for — and the operational
problem we built Serendipity AI to address.

The complete discussion is published in **LSE Business Review**.

---

## Why a serendipity mindset is crucial to make AI a success

- Author: Jim Marshall
- Published: 2022-02-22
- URL: https://serendipity.ai/blog/serendipity-mindset/
Full article: https://swisscognitive.ch/2022/02/22/why-a-serendipity-mindset-is-crucial-to-make-ai-a-success/?utm_campaign=Artificial%2BIntelligence%2BWeekly&utm_medium=web&utm_source=Artificial_Intelligence_Weekly_263 (Swiss Cognitive)
- Summary: Co-written with serendipity researcher Dr Christian Busch — why AI's biggest opportunities will be left on the table without humans who can connect dots.

> *"The potential opportunities that AI could enable will remain mostly
> untapped if we don't hone our ability to connect the dots and cultivate
> serendipity."*

This piece — written in partnership with serendipity researcher
**Dr Christian Busch** — argues that the constraint on AI value isn't the
models. It's the surrounding humans and the cultures they work in.

Without a serendipity mindset — without curiosity, openness to the adjacent,
and the discipline to follow weak signals — most of what AI surfaces will
go unused. We'll be drowning in correctly-identified opportunities that
nobody acts on.

The full article was published on **Swiss Cognitive**.

---

## Serendipity is the key that unlocks strategic advantage

- Author: Jim Marshall
- Published: 2021-11-29
- URL: https://serendipity.ai/blog/serendipity-strategic-advantage/
Full article: https://www.forbes.com/sites/worldeconomicforum/2022/01/19/these-are-the-3-ways-knowledge-can-provide-strategic-advantage/?sh=1c5eccd01803 (Forbes / World Economic Forum)
- Summary: On knowledge asymmetry, Hayek, echo chambers, and why most organisations miss solutions they already have access to. As featured on Forbes and the WEF Davos Agenda 2022.

This piece — also published on **Forbes** and as part of the **World
Economic Forum's Davos Agenda 2022** — argues that *knowledge asymmetry*
creates the deepest competitive disadvantage across industries, and that
most organisations sit on solutions to their own problems without
recognising them.

Proven solutions abound. AI systems that outperform radiologists.
Autonomous vehicle stacks. Whole categories of efficiency. And yet
organisations consistently fail to recognise or apply them.

The cause is largely **information overload**. With billions of pieces of
content created daily, meaningful knowledge is obscured by noise — and
inside organisations, echo chambers and groupthink narrow the aperture
even further.

Drawing on Hayek's economic theory about distributed knowledge, the piece
argues that organisations benefit most when they actively escape their
own filter bubbles. Serendipity AI was built to make that practical.

## The three characteristics

We focus on knowledge that is simultaneously:

1. **Transformative** — has potential to reshape an industry or business
   model
2. **Applicable** — relevant to the specific circumstances of an individual
   or organisation
3. **Actionable** — practical, and not yet widely implemented

Breakthrough innovations frequently emerge at the **intersection** of
disparate fields — virtual reality and education, biology and machine
learning, economics and protocol design. Rather than overwhelming users
with raw volume, the goal is a personalised *digital sidekick* that
continuously identifies these strategic opportunities for its principal.

Read the full piece on Forbes or the WEF Davos Agenda 2022.

---