Article VII

Preface

We spent two years and significant R&D to build this site, because we wanted to challenge ourselves, and push our little corner of the industry forward. We wanted to show what digital interfaces should feel like, prove that we could build our own knowledge-based product, and demonstrate that small, independent teams can contribute to UI/UX leadership just as effectively as large organizations.

We wanted to share what worked, what didn't. We hope you enjoy it.

The Near Future of Interfaces & Design Engineering

If you visit littleplains.com and write "typography inspiration," within seconds you will get back dozens of relevant real artifacts from the past two years of our work and writings. You'll be presented with a river of films, frames, identities, and images that were never tagged on our end. Each artifact also links to the articles it is a part of.

This works because of a system underneath the site that took a year and a half to build. This dynamic and interactive setup was a byproduct of a series of side quests and internal experiments.

Through trial and error, we've stumbled into where we think the near future of interfaces are headed, and how the design engineering practices to create them will work.

Building a Knowledge Layer

Archive Everything

This site began internally as an archiving project. At the beginning of starting Little Plains, we dusted off old hard drives from our prior agency, Gin Lane, which we ran for over a decade. We were sitting on hundreds of gigabytes of valuable, contextual knowledge; writing, philosophies, decks, projects, films, and internal memos.

Using note-taking applications, we also were starting to build a fledgling library of voice notes and meeting records from Little Plains.

We saw what AI was capable of doing based on other people's data, and we wanted to build our own version of a knowledge center. One that was based on our unique, weird, idiosyncratic ways of thinking and working, honed over thousands of hours.

We wanted our own materials to pull from, not the publicly available general information on agency thinking.

Access Everything

Slow and steady, we made all of our archival knowledge and internal nuances indexable, searchable, and conversationally accessible. Once we organized this data, we built a series of agents to query it, cite it, and act on it. While they were rudimentary and academic, it was a cool start!

Conversation & Query

Soon thereafter, we set out to build our first product on top of this knowledge layer. As we were thinking about our new site we realized it would be nice for potential clients, talent, investors and peers in the industry to also be able to access the public side of our information. To do this, we landed on creating three ways into the public versions of this content: visual search, dynamic chat, and voice.

Design in Code

We designed the current experience almost entirely in code. We didn't start with this in mind, nor even initially considered it. After over a year of traditionally designing and building our agency site, a few months ago we switched to prompt-led labs and working prototypes where all decisions were made in a browser. We didn’t look back.

DIY

It took two years, a lot of money and time, and a great revolving cast of specialists, but we shipped a unique user experience on top of the knowledge base. We did it, and we learned so much through this process.

Why This Matters

Each and every company is sitting on their version of a retrievable, valuable knowledge platform. Your years of decisions, thinking, and finished work sit mostly inert, lost to time or stuck in someone's head. We started calling ours "dead stock;" it was valuable, and almost impossible to access. Let's change that!

How We Built a Knowledge Layer

Organized and Usable Are Different Projects

Our first pass was about recovery: what do we keep, which version is authoritative, what project does each document belong to, how does our prior agency's thinking connect to Little Plains' current work.

We finished this pass, and then redid most of it, because while our archive read well for someone browsing folders, it still failed as a retrieval system.

For example, a transcript can preserve an entire meeting and bury the one decision that mattered, and a project folder can hold every final asset while describing none of them.

Thus, our second pass became focused on translation; the sources are ingested and normalized, records are connected to the right entities, public and private material are separated, and everything is indexed in the shape the products would actually query.

Throughout this part of the process, we kept sources separate from any interpretation of it. Our first approved corpus release made this concrete as we organized down to 125 original files in private storage, with each original preserved as its own document.

Next, text and markdown were normalized without being rewritten. PDFs used embedded text first and fell back to OCR (optical character recognition) only when a page had none. Failed and unsupported files stayed visible as failed records instead of vanishing from the count. Lastly, no generative summary sits between the original and the index.

The retrieval system we created is free to transform source material, while staying honest that the transformation is a derivative.

Why 'Chat With Your Files' Is Limiting

We had started with the idea of "chatting with your files." This direction failed pretty early on, because useful organizational knowledge requires editorial judgment. Meaning, what matters, where it came from, what should be instant, what deserves research, what's public, and who approves a change before our system starts treating it as true.

Answering those questions gave us a knowledge-retrieval asset that would last beyond whatever interface we put on top. If we skipped this, we’d have a chatbot that would confidently make up our own history.

Split Fast Knowledge From Deep Knowledge

We found that embeddings were the easy part, yet meaning was hard. How much authority does one meeting transcript carry? What happens when two sources disagree? Which facts should be instant, and which deserve a search?

We decided to split the archive in two:

Deep knowledge is the full corpus. It holds the original documents, transcripts, project files, raw writing, and historical context. It is large, nuanced, and worth searching when a question needs research.

Fast knowledge is a small versioned set of what the site needs available right now. It has four maintained documents:

• Who Little Plains is
• How we work
• Sales, pricing, and process questions
• Rules for how the agent should answer

Versus being a live database pull, each document is written by a person or an agent synthesizing the underlying material, and it only changes when someone or the system initiates an update. Examples would be a new team title, a shift in how we talk about client work, or a pricing change. The website receives whatever's currently published as one compact context pack.

If a user asks about a current project, the site should already know the client, problem, approach, and outcome.

If a user asks about the history behind a decision, then it should go research the archive.

Generate Project Facts Deterministically

We have a single Markdown fact sheet covering each current Little Plains project. It’s rendered directly from approved Sanity fields that have gone through a few rounds of revision. The first version tried to hold too much and broke the model's context limit, which slowed everything down.

Each project's entry contains:

• Title
• Canonical slug
• Publish date
• Capabilities
• Industries
• Tags
• Summary
• Problem
• Approach
• Outcome
• Deliverables
• Retrieval aliases
• Selected assets

Importantly, a model doesn’t write the above. It's a versioned document carrying a source digest, project count, renderer fingerprint, and a stable directory the frontend can validate and cache.

We upload the asset and the pipeline handles the rest. This decision removes an entire class of failure because the agent can describe a client project without improvising, as the facts arrive pre-approved.

Teach the System to See

We're a visual company, so a system that understands case study copy while staying blind to the work itself would have been only half useful.

For example, generic tags like blue, person, or outdoors can miss what a good creative would notice. We wanted our search to also work across composition, art direction, medium, palette, motion, motif, atmosphere, and subject.

To do this, we had our pipeline start in our CMS (Sanity), which stays our source of truth. The backend recursively walks each published Project and Writing, finds the media nested inside, and creates an asset record per placement. The same file can appear as a hero, a process image, and a gallery frame, carrying different meanings in each context.

GPT-5.5 produces versioned structured enrichment for eligible images:

• Visual description
• Detected text
• Colors
• Objects
• Materials
• Mood and style
• Industry
• Use case signals
• Stated uncertainty
• Concise searchable text

Gemini Embedding 2 converts:

• Images
• Available video
• Project and writing chunks
• Analysis text
• User queries
• Reference images

into 1,536-dimensional vectors, where PostgreSQL and pgvector store and compare them.

Ranking blends visual similarity with exact and full-text relevance, analysis text, normalized tags, metadata, project context, and local curation. In the current mix, text carries slightly more weight than raw visual similarity, with tags, support signals, and a gentle "great example" boost filling in the rest.

Thus, a literal phrase like "national park" can beat a vaguely similar image, while "blue talking orbs" still finds work that nobody manually tagged.

Additionally, model-generated interpretation counts as evidence, and authored language and editorial judgment outrank it.

Give Each Intent Its Own Retrieval Path

As detailed above, our first interface was chat, and it treated every question as a research project. It would search the corpus, retrieve sources, interpret, and assemble an answer. That was great for a hard historical question. It fell flat for something as simple as "what does Little Plains do."

It worked. It was also slow as heck.

Fast knowledge fixed part of that problem. Splitting the interface fixed the rest once we accepted that people arrive with different intents. Some want to browse, some want a specific answer, and some want a conversation.

Explore:

This modal turns a phrase or a reference image into a field of work. With the query normalized and an embedding created, candidates are pulled from direct asset vectors and supporting analysis vectors, then blended with exact text, tags, metadata, project relationships, filters, and curation.

The public response reduces to safe render-ready cards, with raw analysis, vector scores, and provenance staying behind the API.

Results land in a masonry grid because the assets span four or five aspect ratios and uniform crops would have wrecked them. Right click any card for "find visually similar," running the same pipeline.

Ask:

Turns a question into a grounded structured response. GPT-5.6 Luna is used at low reasoning on OpenAI's Fast tier, starting from the reviewed knowledge pack, canonical site facts, a compact project directory, the current page, and recent conversation.

Luna picks among explicit tools for project identity, structured project facts, full case study detail, exact Info and Career records, deep archival search, and visual retrieval. The planner makes the semantic call, and the tools keep its authority narrow and testable.

Luna returns an answer, two candidate follow-ups, an optional set of validated projects or media, an optional page handoff, and a decision on any pending handoff. The server validates all of it before the interface executes anything. That's how a sentence becomes a project card or a media board while the model stays away from the browser.

Voice:

This shares the same product as above. We also used GPT Realtime 2.1 with the Marin voice, semantic turn detection, and GPT-4o mini transcription. Typed and spoken modes receive identical ordered grounding and reconcile into one transcript, so switching mid-conversation continues rather than restarts.

Realtime answers ordinary studio questions from shared context and delegates substantive project questions to the same Luna planner, then narrates the validated written result. Interruption, stale events, transcript ownership, and microphone state all receive explicit handling.

Explore, Ask, and Voice share source entities, asset relationships, embeddings, and APIs, yet each one still gets its own query path. Pretty cool :)

Pick Models per Job, Then Prove It

We used five models for five jobs:

• GPT-5.5 enriches images
• Gemini Embedding 2 handles each vector
• Luna plans typed Ask
• GPT-5.6 Sol evaluates the public agent and powers higher-reasoning internal workflows
• GPT Realtime 2.1 runs voice

These each came from evaluation, rather than leaderboards. We froze 74 scenarios covering:

• Studio facts
• Current and archival projects
• Visual retrieval
• Navigation
• Follow-ups
• Ambiguous names
• Missing data
• Prompt extraction attempts

We used three runs each with Luna, then had Sol judge all 222 outputs against public evidence and the rendered UI contract.

For us, the score mattered less than the failure list. An ambiguous project prefix has to trigger clarification. A request for "recent" work needs a real launch date rather than editorial order. A full case study has to fit the structured output envelope. A visual board can't invent palette details because the images look related.

Each one of these is interface behavior, and the model would just widen the surface.

Latency got the same treatment. With our holding model, reasoning level, 800-token allowance, tools, and test cases fixed, we moved from Standard to Fast processing and cut the median planner turn from 6.1 seconds to 3.6 seconds. Fast cost roughly 1.9 times as much, and we paid it, because the API call was nearly all of the waiting.

Design in Code

Figma vs. Git as a Source of Truth

We used Figma to build our v1 stylesheet, design system, and atomic kit, and those became the language we fed to coding agents. Figma stayed useful for visual studies and component work.

However, Figma stopped being where we answered the hardest questions for the site build, because those questions involved state, timing, motion, live retrieval, focus, and browser behavior.

A static frame suggests how something moves. Only working software shows you how it feels through interaction when real results arrive, the keyboard opens, or a transition reverses halfway. Once you experience this, it's hard to go back.

The loop became:

• Idea from Slack, Wisprflow, or transcribed from a meeting
• Rough lab in Codex or Claude Code
• Shared URL
• Supercut feedback, MCP into Linear, then a ticket, then a pull request

Our labs stayed deliberately incomplete, a navigation lab needs no production data and no full agent, it just needs to prove whether three modes can feel like one object.

The site’s unique navigation UI is the clearest example of this. To get to our Omnibar, we talked through endless paradigms out loud into Wisprflow while Codex built a half dozen working variations in parallel.

For us, going from spoken thought to clickable prototype in minutes, repeatedly, is what made that range reachable. Again, once you experience this model of creating, it’s hard to go back.

Codex then built these six variations. We tested them, tinkered, and we then decided which versions to ship. We then rinsed, and repeated. More options raise the need for curation, and this is where having an opinion and intention matter, a lot.

Human input > agentic modeling > human curation.

This iterative process for our navigation produced the Omnibar, where Explore, Ask, and About became three modes of one persistent object instead of three destinations.

The bar has a long and intentionally considered (through endless edgecase testing) set of parameters and guidelines for both desktop and mobile, two extremely different use cases for a multi-modal, persistently on screen, full-site navigation.

Omnibar varies across mode, presentation, page context, viewport, focus, and conversation state, and every combination changes labels, controls, dimensions, and motion.

None of that would have been possible to feel in Figma; it only came together by building in the browser.

Build Your Own Knowledge Layer

A Step by Step Guide to Building Your Own Knowledge Layer

Here are eight steps, in the order we'd repeat them (and save a lot of time):

Name the Question Before You Build Anything

• Pick the key things your team keeps answering by hand, over and over. For the site, ours was "What can Little Plains do? What has Little Plains done?"
• Let that question decide what you build first. Architecture built for a real need stays honest. Architecture drawn first goes looking for a product to justify it.

Preserve Sources Before You Transform Anything

• Keep every original as its own document.
• Normalize without rewriting.
• Let failed files stay visible as failures.
• Never insert a generated summary between the source and the index.

Write Your Fast Layer by Hand

• Four to six documents covering who you are, how you work, what people always ask, and how the agent should behave.
• Do this before you touch embeddings. It's the single most valuable part of the whole project.

Render Structured Facts Deterministically

• Anything with approved fields in your CMS should produce a versioned fact sheet with a source digest.
• Models improvise, renderers don't.

Separate the Placement From the File

• One image in three contexts is three records.
• Context carries most of the meaning.

Route by Intent Instead of One Catch-All Query

• Browsing, answering, and speaking are different retrieval problems with different latency budgets.

Build the Eval Suite Before You Tune Anything

• Freeze scenarios, run each several times, have a stronger model judge against your actual UI contract.
• You're farming a failure list, not a score.

Keep a Person in the Publishing Loop

• A model proposes line-level changes, and a human accepts, rejects, or rewrites.
• Publication creates immutable versions.
• Nothing said in a meeting quietly becomes public truth.

Four things to watch for:

1. Chat-first interfaces create a blank canvas problem. An empty input asks visitors to know what they want before they've seen anything. Show artifacts first, take questions second.
2. Treating every question as research makes common answers slow and complex answers shallow.
3. Model-generated interpretation will quietly outrank your team's own writing unless you weigh against it.
4. And once anyone can ship, branches start encoding contradictory interaction rules. Merge conflicts are solvable. A product holding five competing ideas about what it is takes much longer to fix.

Knowledge Centers, Designing in Code, & The Joy of Tinkering

Through this journey, we took away three lessons for teams exploring their own comparable process:

1. Use the valuable knowledge you already have
2. Build software with prototypes that can replace a static design file
3. Experiment and tinker

Here's what we'd tell ourselves if we were just starting the same project from the beginning:

Build Your Own Knowledge Center

Decide what's public and what stays yours, learn to shape UI around information in code, and learn to point agentic tools at your own material and direct the flow. 

Start now!

Transcribe and save your internal workshops, calls, and document your workflows, culture, team structure, and oral history. Connect your work files, code, and conversations.

You’ll have a baby corpus of information within a month. Within a year, you will have so much rich proprietary information in one place for your team and agents to access, you will feel like a new company.

Design the Language in Figma, Design the Product in Code

Once the team started building in Codex and Claude Code instead of designing in Figma first, the working prototype itself became the place where decisions got made.

When we had an idea for the Omnibar, we didn’t write it up and present it. We built a rough version, sent a link around, the team clicked through it on their phones, argued about what felt right, and that argument happened inside the software itself. The prototype was the source of truth and each project team member began directly contributing to it.

Our new website is the visible result; one lasting change is that working software became the place our team thinks together. This also included many team members who had never coded, setup a git, done pull requests, or shipped anything.

Experiment and Tinker

Some of the best parts of the site were never planned. Dan Batten built a searchable visual archive of an internal Slack channel as a weekend project, and it became the seed months later for our site’s image-based discovery UI.

Rusty Meadows built an internal tool to check if the image pipeline was working, and on a call reviewing it, we realized it was better than anything visitors could actually use on the live site. We forked it. That tool is Explore.

Alex Leiphart prompt-engineered a microsite for our proposals that served as the nerve center for our final site’s push.

Give your team room to build things nobody put on a roadmap. Most side projects won't ship, and that's fine, most shouldn't. But you won't find the version of your product that surprises you if every hour has to be justified in advance.

None of the above would have been possible without the tools to try things quickly and cheaply. Create a culture to try things you don't need permission for. Lose some money and time. In the long run, it’s well worth it.

In Conclusion

As bleeding-edge agentic technology becomes increasingly affordable, your own context is one of the best places to invest. Built in browser, thoughtfully. And make time to tinker.

We hope this helps you get started on your journey. Thank you for reading.

Please email us at hello@littleplains.co.

Emmett Shine, Alex Leiphart, Rusty Meadows contributed to this essay for Little Plains, a New York studio working with startups on brand, product, and the technological systems that bond them together.