You know exactly which app would make your week easier, and it's been stuck in someone else's backlog for months. Maybe you filed the request, or maybe you kept updating a spreadsheet by hand while you waited.
What if describing that app in plain words were enough to build it? Now that you can, who gets to build enterprise software is starting to shift. Here's why your next enterprise app will come from the people who use it every day, and how that idea shaped apps in AgentSpot.
Haven't Users Always Built Their Own Apps?
Think about the most useful tool on your team. Is it the platform that launched last year with an email and a training session, or is it the color-coded, 12-tab spreadsheet that one person built and nobody dares to touch?
People have always built their own apps with spreadsheets, Access databases, macros, and shared docs with a "do not edit" banner at the top. Why do those tools exist? The people closest to the work know exactly what they need, and they couldn't wait for it. Those smart workarounds have kept plenty of teams like yours running.
So what was missing? A real app with live data and working buttons used to require a developer and a spot in the backlog. Low-code tools helped, though you still had to learn a tool before you could build anything.
That last barrier is gone: you can describe the app you want in your own words and watch it get built. Most conversations about multi-agent AI focus on what agents can do. Who gets to build with them, though? Increasingly, the answer is the people who use those apps every day.
Can You Build an App Through Conversation?
Every enterprise app already starts as a conversation, where someone explains what they need and someone else turns it into a spec. When the build comes back a few sprints later, you find out what got lost in translation.
Now take out the translation step. Once building becomes the conversation itself, you describe the problem and the builder asks how you want it to look before showing you the result.
In AgentSpot, your first decision comes before anything gets built. When you describe an app, the builder proposes distinct design styles and asks you to pick one. If you skip the picker, it goes with the top option.
Once you've picked a style, the build starts, and a work timeline shows its progress. When generation is complete, a preview of your app appears beside the chat panel. The builder follows a simple rule: you own the intent, and it owns the code. Say "make the revenue number bigger" or "break this down by region," and it works out how.
Will you ever need to read a line of code? No. Here's the practical test: if you can explain the job to a new teammate, you can build the app for it.
Can Subject Matter Experts Direct Their Apps?
For years, the people with the business context and the people with the skills to build rarely sat in the same seat. Subject matter experts (SMEs) wrote the requirements while someone else made the calls. When building is a conversation, you make the calls.
Think of it like film: you hold the script and sit in the director's chair for the whole shoot. Here's what you direct, and what it looks like in practice:
| What You Direct | What It Looks Like |
|---|
| How it looks and feels | "Make it feel like our board deck: dark background, our brand colors, one big number up top." |
| Which information it pulls | "Use our pipeline model in ThoughtSpot and the open opportunities in Salesforce." |
| Which actions it takes | "Add a button that posts this summary to the team's Slack channel." |
| Who gets to see it | A couple of clicks to share it with your regional managers, or with the whole company. |
If you underline one row, make it the actions row. Why? An app that only displays numbers gets checked once a week, while an app that lets you act on them becomes part of how you work.
What would that look like in a renewal tracker for your customer success team? Seeing which accounts are at risk is useful. When you can also update the opportunity in Salesforce or give the account team a heads-up in Slack from the same screen, you save the afternoon. Because you shaped the app around your work, you can keep reshaping it as the work changes.
Once an app pulls from one system and acts in another, it starts to resemble a multi-agent system, with connected pieces working across your tools on one job. The difference is that you designed it in a conversation, and AgentSpot tries to make that director's job feel natural.
If you've set a style before, the builder can reuse design preferences saved in your personal or organization memory. Actions are just as deliberate: each one runs only when a viewer triggers it and confirms, never automatically. Since nothing runs on load, simply opening an app never changes anything.
Does a Shared App Expose Everyone's Data?
Sharing is where user-built apps used to fall apart. The spreadsheet one person built had that person's data in it, so sharing it meant either exposing too much or spending your afternoon making a copy for every region.
Ever received a file called "pipeline_v3_FINAL_east.xlsx"? Then you know how that story ends.
A user-built app should work like a window, where you build it once and each viewer sees their own live view. Whenever someone opens an app in AgentSpot, the data is scoped to their permissions.
Your sales VP and a sales rep can open the same pipeline app, and each sees exactly the slice of data they're allowed to see. You design the experience, while your company's existing permissions decide the data. Because every viewer gets live analytics scoped to their own access, sharing becomes safe enough to do freely.
That freedom is how one person's good idea becomes the way a whole team works. It's also the thinking behind AgentSpot as Multiplayer AI: once you build an app, your whole team can use it.
Why Do People Value What They Build?
Behavioral researchers have a name for it: the IKEA effect. In four studies, Harvard Business School's Michael Norton and his co-authors found that people valued their own creations about as highly as experts' work. You probably feel the same way about the bookshelf you assembled yourself, even if it wobbles a little.
The same research adds a catch that matters for apps: the effect faded when people failed to finish what they built. So what happens to the enterprise software you never helped build? Apps pushed to you from above tend to drift away from how you actually work, and nobody feels responsible for fixing them because nobody feels they're theirs.
User-built apps flip that dynamic. When the app is yours, you notice when something is off, and you fix it the moment it bugs you. You might add the column your manager keeps asking for in every 1:1, then share the update with your team.
That build-use-improve loop only holds up if improving is as easy as building, which is why editing an app in AgentSpot is the same conversation you started with. Because your changes go live only when you publish, your team never stumbles on a half-finished version.
What about everyone else on your team? Colleagues can discover your app when they browse published apps, then duplicate it and adapt the copy for their own work. Discover cards show how many people are using an app.
How Do Admins Govern User-Built Enterprise Apps?
If everyone can build apps, doesn't it turn into the wild west? Hundreds of apps plugged into everything and shared with everyone is a fair objection.
It doesn't have to go that way, because user-built apps work in the enterprise only when the guardrails live in the platform itself. When they do, you get creative freedom on top of a foundation you can't break. Here's what those guardrails look like in practice:
Your admins decide which connectors are available, so if Salesforce, Jira, or Slack isn't turned on for your company, it isn't an option in the builder.
Once a connector is turned on, admins can still allow or block individual tools on it.
You sign in to each connector with your own credentials, so you can only reach data and perform actions you're already authorized to.
Because connector data is scoped to each user's own access, nobody borrows a colleague's access through a shared app.
ThoughtSpot models keep their row-level and column-level security, enforced automatically for every viewer with no back door.
Guardrails like these also give IT and data teams a better role: curating the trusted data models and approved connections your apps are built on. You build on top, and everyone spends more time on the work they do best.
How Do You Build Your First App?
Where should you start? These four tips will help your first app earn a place in your team's week.
Start with the Spreadsheet Everyone Uses
Your best first app is probably hiding in plain sight: the spreadsheet your team updates by hand every week. Describe what it tracks and who looks at it, then let the builder take it from there.
Pick a Design Style Your Team Recognizes
Because AgentSpot proposes distinct design styles before it builds, pick the one that matches how your team already reads its numbers. If you've saved design preferences in memory, they show up as ready-made options, which saves you a few rounds of edits later.
Add the Action People Take Next
What do people do right after they look at the numbers? Add that step to the app, so the next move is one click away.
Share Early and Listen to Your Team
Once a first version works, share it with a few teammates sooner than feels comfortable. Their feedback will shape the app more than another hour of polishing.
Want to See AgentSpot Build Your App?
As building gets easier, the question inside your company shifts from "who can build this?" to "what should we build next?" The app you've been waiting on might be one conversation away.
If you'd like to watch that conversation play out with a use case from your own team, request a demo. You'll see the design styles, the live preview, and the admin guardrails in action.
Request a demo
P.S. That 12-tab spreadsheet nobody dares to touch? It's earned its retirement.
