AI visibility (GEO/AEO) platform

I was the sole engineer on an AI-visibility (GEO) platform — the product that measures how a brand shows up in the answers AI assistants give, and helps improve it. I owned it end to end, from the first architecture decision to a system running in production.

Context

Answer engines don’t rank ten blue links; they synthesise a response and cite a handful of sources. Measuring and influencing that means running many prompts across several assistants, capturing what each one says and which sources it leans on, and turning raw transcripts into something a brand can act on — repeatably, and cheaply enough to run often.

What I built

A TypeScript monorepo deployed as multiple services with CI/CD. Multi-agent pipelines measure visibility, analyse the answers and produce reports. A Node.js API sits in front of background workers and queues; a Next.js dashboard, an admin panel and a browser extension are the surfaces people use. Two MCP servers expose the platform’s capabilities to AI clients and to internal tooling.

Architecture and decisions

Agents behind a queue. Visibility runs are slow and rate-limited, so the API never calls an LLM inline. Work goes onto a queue and is processed by background workers, which keeps the API responsive and makes the expensive calls retryable and idempotent.

An agent-harness runtime. The agents run inside a harness that schedules them, enforces budgets, records a trace of every step and recovers cleanly when one fails — with its own object store for run artifacts. Two MCP servers (a public one and an admin one) expose the platform to AI clients and internal tooling.

Multi-provider by design. The platform runs against OpenAI, Anthropic, Google and Perplexity. Prompts and pipelines are written once and evaluated for answer quality, so a provider can be swapped or compared without rewriting the pipeline.

Explicit state and traces. Each run is a durable record; each step writes its inputs and outputs. PostgreSQL holds relational state, Redis backs the queues and caching, and MinIO stores large artifacts out of the database. OpenTelemetry traces every run, so when an answer looks wrong the trace says why — that observability is what made a fleet of non-deterministic agents operable.

My role

Everything: architecture, the API, the workers, the data model, the agent pipelines, the MCP servers, the dashboard and the browser extension, plus DevOps — Railway, Vercel, Docker, monitoring and observability. Full technical ownership, solo.

What I’d keep

The trace-first design is the part I would keep. Making every run a durable, traced record is what turned a fleet of non-deterministic agents into something I could debug and change in production.