What Is the Smallest (AI) Platform That Could Possibly Work? | Build to Understand

Build to Understand

Explorations, principles, and systems about engineering freedom.

At Vipps, one of the most common requests I see is access to LLMs. Giving an engineer an API key is easy. It solves the immediate access problem. However, it doesn’t show finance which team created the cost, help compliance understand where the data goes, or give incident response a way to observe the system.

There is always additional work that often comes later, sometimes weeks after the main work. So, when does recurring work justify a platform used by several teams? And if it does, what is the smallest platform that could possibly work?

I am using AI agents as the current case. By agents, I mean software built with LLMs, skills, and integrations with internal or external tools.

01

What Problem Would a Platform Solve?

Organizations want engineers and non-engineers to build useful agents to become either more productive or to create new products. As more people build such agents in whatever form, the same needs and demands appear. Developers need model access and evaluation tools. Finance wants to know which team created what cost. Compliance wants control over data flows and audit evidence. Incident response wants a system it can observe, and the list goes on.

None of these requests alone justifies an AI platform. A team asking for model access has an access problem. The finance department asking about a bill has an accounting problem.<br>A collection of experiments doesn’t become a platform problem just because the experiments use AI.

I start seeing a platform problem when teams repeatedly need the same access controls, a way to connect costs to the teams that created them, evaluation, observability, or audit evidence. At that point, solving every use case separately creates more work, inconsistent controls, or unnecessary risk.

A company may have many experiments and no platform problem. Another company may have only two agents in production that handle sensitive data and already need strict controls. The difference is whether the same problem keeps appearing, what happens when it is ignored, and whether solving it once for several teams would remove more work than it creates.

Even then, the answer may be to extend an existing platform. I would consider a dedicated AI platform only when existing systems can’t solve the repeated problem without every team rebuilding the same AI-specific components.

What Is Actually Repeating?

Repeating work doesn’t always look the same. I have seen two examples often enough to be mentioned here.

Pattern 01

Deployment support repeats

Analysts and product managers use Claude Code or Codex to build something—perhaps a dashboard. It works on their machine. Making it available to others means deploying it to the company runtime environment.

At Vipps, services follow a contract available through the internal developer portal. Using it still requires engineering experience, so the platform team repeatedly provides manual help.

Signal: the same setup and translation work returns with every new builder.

Pattern 02

Access without controls repeats

Engineers build AI-powered Slack apps and ask for an API key to an LLM. The request itself takes little time.

But handing out a key doesn't show which team created each cost or provide data controls, evaluation, or useful observability.

Signal: easy access creates the same unanswered operational questions.

The first example repeats deployment support. The second repeats access without the controls other stakeholders need. Both are problems a platform might solve.

Our AI Playground removes part of the first problem. A (non-)engineer visits our internal developer portal, gives an agent a name, and receives a repository with a working agent deployed to the test environment. The (non-)engineer also receives a starter prompt for a coding agent. The value is the repeated setup that the template removes, the company’s allowed technologies it uses, and the best practices that are added as skills.

When Should Several Teams Use the Same Service?

Teams may repeat work because they are still learning. Centralizing it too early can turn experiments into a service nobody wants and needs. I would consider building a shared service only when repeated work blocks a useful workflow or creates visible cost, risk, incidents, or audit work.

Before I build a shared service for several teams, I should also ask whether the workflow is needed or whether the repeated work can be removed. The apparent platform problem may be unclear ownership, missing training, or a workflow that should simply be removed.

My next test is important for me:

The order matters. Start with documentation. If that isn’t enough, establish a convention, then consider a template, a library, or a CLI. Build a managed service only when the simpler interventions cannot remove the repeated work.

A...