# An internal operations platform, two years on

> An internal AI operations platform for an agency. It started as a first build, grew into a two-year partnership, and became the platform the agency's team runs its operations on.

- Client: An agency (anonymous)
- Type: Internal AI operations platform
- Category: Internal AI operations platform
- Duration: 2 years, grown from a first build
- Status: In use, the platform the team runs its operations on
- Role: End to end, first call to launch, then the partnership
- Result: 44 internal users (The scale the platform supports, not measured time savings or revenue.)
- Result: 400+ connected properties (The scale the platform supports, not measured time savings or revenue.)
- Result: ~220k rows a day, on average (The scale the platform supports, not measured time savings or revenue.)
- Built by: Luka Abramović (https://lukaabramovic.com/)
- Canonical: https://lukaabramovic.com/work/internal-ai-operations-platform/

---

## The starting point

The work began as a first build for an agency. Before it, the agency's employees worked across manual processes, separate AI accounts and disconnected data, and each person kept their own prompts and outputs. The first build was a success, and it showed the potential for a larger product that brought those workflows into one system.

## From a first build to the platform a team runs on.

A first build grew into a two-year partnership, and the platform became what the agency's team runs its operations on. It had to carry a lot of data and operational complexity without asking non-technical users to understand the systems underneath it.

### Fragmented work

Prompts, outputs, quality checks, analytics and reporting were spread across separate people and tools.

### Scale

Hundreds of connected properties needed dependable data movement and refresh logic.

### Non-technical users

Complex configuration and analytics had to make sense without exposing implementation detail.

## My role

I ran this end to end, from the first call through discovery, scope, solution design and leading the build with the Adamant Code team, to launch. After the first build, the work continued as a two-year partnership.

1. First call
2. Discovery
3. Scope & proposal
4. Solution design
5. Build lead
6. Launch
7. Iteration

<StepDiagram
  label="Diagram: 400+ connected properties feed one internal platform, which takes in about 220k rows a day on average and is used by 44 internal users"
  steps={[
    { label: 'Connected properties', detail: '400+ sources feeding one platform' },
    { label: 'The platform', detail: 'About 220k rows a day, on average', tone: 'accent' },
    { label: 'The team', detail: '44 internal users run their operations on it', tone: 'dashed' },
  ]}
>
The scale the platform supports, not measured time savings or revenue. Diagram only: the client is anonymous.
</StepDiagram>

## One platform for the team's operations.

The platform connects operational data, user requests, AI generation and review in one place. With the Adamant Code team, I worked across product strategy, workflow design, data engineering, AI behaviour, dashboard UX, permissions and reliability. The aim was to make complex internal operations feel like one coherent product.

1. Scheduled pipelines collect and refresh the operational data from the connected properties.
2. A user starts from a dashboard or a natural-language request, without managing the systems underneath.
3. The platform generates an internal output or analyses the operational data.
4. The result stays in the product, so the user can check its quality and move on to the next step.

## Built for everyday use.

A platform a team runs on has to work well past a single good request. Permissions, scheduled work and reliability controls carry the team through recurring operations.

### Operational data pipelines

Large recurring data flows connect hundreds of properties to internal dashboards and workflows.

### Natural-language analytics

Users explore operational information without working directly with the data layer.

### Roles and scheduled work

Permissions, recurring jobs and refresh schedules keep access and execution organised.

### Reliability controls

Failure handling, API-limit management and data-quality checks support everyday use.

## Two years on, the team runs on it.

The platform is what the agency's team runs its operations on, two years after the first build. The numbers below are the scale it supports, not measured time savings or revenue.

<MetricTiles
  size="m"
  items={[
    { value: '44', note: 'Internal users. The scale the platform supports.' },
    { value: '400+', note: 'Connected properties. The scale the platform supports.' },
  ]}
/>

## What this proves

The test of an internal platform is whether a team still runs on it years later. This one started as a first build and is still the place the work happens two years on.