← Projects

AI Agents Context Management Feature

A shared library of versioned instructions that every client agent draws from, so a change is made once and reaches every assistant using it.

Role
AI Engineer Intern
Organization
Atria
Location
Pittsburgh, USA
Industry
Artificial Intelligence / SaaS
Timeline
Jun – Aug 2025
Stack
  • React
  • JavaScript
  • Node.js
  • Express
  • MongoDB
Agent context · pieces and assemblyeditingunsaved changes
1Library350+ pieces
Search pieces, sections or categories
  • Cross industry
  • Restaurants
  • E commerce
  • Collections
  • Health
  • Hotels

Identity

  • Who the agent is52
  • How it introduces itself48
  • What it must not do52

Booking

  • Table availability14
  • Room availability6
  • Appointment slots5

Payments

  • Overdue balance11
  • Payment plan offer9
  • Refund window8

Compliance

  • What it may not advise5
  • How it records consent11
2Assembledrag to order

  • 1Identity

    • Who the agent is
    • What it must not do

  • 2Scope

    • Table availability

  • 3Tone of voice

    • How it answers

  • 4Escalationempty

Drop a section here to remove it

3Compilethe prompt

## IDENTITY

## SCOPE

## TONE OF VOICE

A section becomes a heading. A piece becomes the text under it, and its name never ships.

Two ways to look at the same idea, on the cards above. Context assembly follows a context being built from reusable pieces and compiled into the prompt the agent runs on. Inside a piece opens one of those pieces: what it holds, what an edit changes, and which sections it can be added to.

Problem

Any team running agents for many clients in one industry meets the same wall. The same instruction gets written into every deployment and then drifts, because a prompt is treated as text inside an agent rather than as an artifact with versions, owners and consumers. Atria was an early stage startup still deciding how its agent platform should work, and I joined as an intern while that shape was being defined. Agents for food, collections and service clients each carried their own context, and onboarding a client meant writing one again from the beginning.

Solution

The design makes an instruction a reusable artifact rather than text inside an agent. A piece is authored once, carries a version and the industry it belongs to, and lives in a shared library. A context is an ordered set of sections, each holding pieces, and it is compiled at the boundary into the prompt the agent runs on. Saving a piece propagates it into every context that references it, so the library stays the source of truth and the deployments are consumers of it. It grew to 350+ reusable and versioned instructions serving 50+ client deployments.

Before, a copy in eachwho_the_agent_isv1, as first writtenpasted in by handclient onefoodits own copywho_the_agent_isv1 plus a local fixpasted in by handclient twocollectionsits own copywho_the_agent_isv1, never updatedpasted in by handclient threeserviceits own copywho_the_agent_isrewritten by handpasted in by handclient fourfoodits own copyFour copies of one sentence, already four different sentences.After, one they shareThe library pieceWritten once, versioned,tagged by the industryit belongs tov4 · 350+ pieces · 6 industriesone edit, on savePropagationRewrites the copy insideevery context that holdsthe piece, then recompilespieces.api.controller.jsevery reference, 50+ in allclient onefoodreferences itclient twocollectionsreferences itclient threeservicereferences itclient fourfoodreferences itand 50+ moreOne edit reaches every assistant that references the piece.Before, the same change had to be applied deployment by deployment, and the copies drifted between applications.After, the library is the source of truth: the piece is edited once and every context that holds it is rewritten and recompiled.
The figure shows one assistant, so the scale is invisible there. Before, the same sentence lived in every deployment and drifted between edits. After, it lives once and the deployments reference it, which is the whole of the feature in one picture.

What made this possible

  • Versions, not edits

    A piece keeps its history, so a change can be read, compared and rolled back. Without that, pushing one edit into 50+ deployments would be a risk rather than a feature.

  • Propagation on write

    The fan out happens when a piece is saved, not when an agent runs. No agent waits on the library, and every context is already consistent by the time it is used.

  • Compiling at the boundary

    A context stays structured data until the last moment, when it becomes the prompt. Structure is what can be reordered, cloned and reasoned about; the prompt is only the output.

Impact

Onboarding a client became assembling a context rather than writing one. A policy or a tone change is made once and reaches every assistant that uses it, instead of being applied deployment by deployment, and the same library now backs 50+ deployments across food, collections and service clients.

← Back to projects