Building agent-native software

Most SaaS products right now are doing the same thing: slap an AI layer on a decade-old workflow, park a chatbot in the corner, and ship.

The problem is not that users need another assistant. The software itself is still rigid. Fixed screens, fixed workflows, one UI for five different roles. A maintenance coordinator and a leasing manager see the same interface. That is not intelligent software. That is software with a chatbot stapled on.

When I started building agent-native solutions at Entrata, the first useful step was to stop thinking in screens. Here is what has held up in practice.

§What agents actually are

Ask five engineers what an agent is and you will get seven answers. The simplest version I use: an agent is a workflow where the LLM makes the decisions.

In a normal app, a user clicks a button, the system checks a condition, calls an API, stores data. Every step is hardcoded. In an agent workflow, you replace "developer decides the next step" with "the LLM decides the next step." Same tools, same APIs, but the path through them is flexible.

§Features vs outcomes

In traditional software, a feature is a function. You define every step, every edge case, you ship the code.

In agent-native software, a feature is an outcome you describe in plain English.

Say you want a weekly review that summarises activity and suggests priorities. The old way: write a function that queries the database, aggregates, formats a report. The agent-native way: write a prompt like "Review files modified this week. Summarise key changes. Suggest three priorities for next week." The agent uses the read and list tools you already built and figures out the rest.

§Build dumb tools, write smart prompts

Agent tools should be small and atomic. Read a file. Write a file. Store a record. Send a message. That is enough.

Do not build a tool called `analyze_and_organize_files`. That bakes the decision-making into the tool. Give the agent `read_file`, `write_file`, `move_file`, then say in the prompt: "Organise the user's files based on content and relevance." The agent decides. The tools just provide capability.

§Action parity

Whatever a user can do in the UI, the agent should be able to do through tools.

If users can create, tag, search, and delete notes in the UI but the agent can only create notes, you have broken action parity. Every time you add a UI feature, ask: can the agent achieve this outcome? If not, add the tool in the same PR.

§Context engineering

What separates a mediocre agent from a useful one is usually context. Not how big the context window is. Whether the agent sees the right information at the right time.

I treat context as a compiled view, not a text dump. Inject what exists now, explain the vocabulary, keep it fresh, keep it structured. The agent's context should mirror what the user sees on screen.

§The loop mindset

Most software is request-response. User sends a request, system responds, done. Agents work in loops.

The agent gets an outcome to achieve. It plans, acts, observes the result, adjusts, acts again. That loop runs until the job is done. A chatbot gives one answer. An agent keeps working.

§Shared workspace

A lot of agent demos put the agent in a sandbox with its own files and data. That is backwards.

Agent and user should work in the same workspace. Same files, same database. When the agent creates a document, the user sees it immediately. When the user edits it, the agent reads those changes. No sync layer, no copy-paste.

§Where this is heading

The current wave of AI-powered products is mostly a UI refresh. The harder shift is structural: software designed around agents from day one, where the agent is how value gets delivered, not a sidebar feature.

That shift is gradual. The messy part is applying these ideas to real products with real constraints and real legacy behind them. That is the work I am doing now.