Agent as Interface (System of Record as Backend)

Artifacts as the unit of work

Sierra's stated design bet is that the agent becomes the primary interface people work through, and the SaaS systems of record it touches become backends behind it.¹ The company states this as the fourth of its numbered lessons: "the agent is the UI, the system of record the backend." The premise is that every piece of real work produces something concrete, an artifact: coding agents found theirs first in the pull request, and every other function has an equivalent, a customer story, a contract, a review, a pitch deck. An artifact is both the input that gives the agent context and the output where the finished work lives. In practice this means asking an agent to tighten a pitch deck and getting the deck itself back updated, not a chat message describing what to change. The conversation is where a person asks; the artifact is where the work lands.

Underneath, the systems of record stay exactly where they are. GitHub still keeps the pull request, Salesforce still keeps the account, Linear still keeps the issue. The agent sits as a layer across all of them, reading from and writing to each through a governed gateway, rather than replacing any one of them.

Why not replace the systems of record

Sierra's own case against replacing incumbent software has two parts. First, replacing a mature system means recreating decades of accumulated workflow, permission, and edge case handling that the incumbent already has. Second, and more important, doing so splits a company in two: people working through the agent and people working directly in the old tools each end up with their own version of the truth. Keeping exactly one system of record per object avoids that split. The bet is therefore not that the agent eats the software stack; it is that the stack becomes the backend, the agent becomes the front end, and there remains exactly one source of truth per object.

Sierra reports building this internally around a single agent, after first trying a set of role-specific agents that failed because the most important work in a company happens across teams, not within them, and because employees had to remember which agent handled which job. Since its first commit the internal agent has run more than 75,000 sessions across over 600 people and opened 70 percent of the company's pull requests, alongside a stated caution that sessions and tool calls measure activity, not the outcome that actually matters, and that a team can make its adoption chart look impressive without anything downstream getting better.¹

The contrast with the consumer case

Brian Chesky makes the customer-facing version of a similar argument in reverse: he agrees that agents succeed apps, but rejects the idea that the successor interface is a text chatbot, arguing instead that a consumer agent needs to be a rich, visual, directly manipulable surface rather than a message thread. Sierra's claim is about the internal agent, where the surface is the artifact plus the system of record's own interface, with the agent as the connective layer. Both positions reject the idea that a chat box is the endpoint, from opposite ends of the same problem: consumer-facing and internal.

Open questions

Whether the backend genuinely recedes or fights back is unresolved, since incumbent software vendors are shipping their own agents that want to be the interface themselves. Writing is also a harder problem than reading: an artifact coming back updated requires reliable write access across every system of record, with the permission scoping and audit trail needed to make that safe, a materially higher bar than read-only querying. And the one-source-of-truth property only holds if the agent is disciplined enough to always write back to the system of record rather than letting work drift into chat threads and local copies.