An app can show you a ticket. Until this week, it could not do anything about it.
The app in the video above is a support desk for a packaging supplier. It pulls Zendesk tickets, HubSpot records, and rows from a production database into one screen, so a support rep stops cycling through three tabs to understand one customer. That alone is useful. It is also, if we are honest, where most internal tools stop: a nicer window onto work that still has to be done by hand.
Embedded agents are live in General Input as of this week, and they change what that window is for. Any app you build can now carry agents that launch from its own interface. This is not a chat widget bolted to the corner: it is the same full agent that runs your background workflows, started from a button inside the app, with the context of whatever you are looking at.
The video builds one end to end in about fifteen minutes. This post is the longer version: what shipped, why launching an agent from inside an app is different from pasting context into a chat window, and what becomes buildable once your interfaces can do their own work.
From interface to operating system
The support desk started the video as a read-only unifier. The whole upgrade was one message to Geni, the agent that builds and edits apps:
Add an agent to this application, visible on each detail page. It should gather context from all of the systems connected to the application, plus Gmail for past interactions, then give a brief of the issue the customer is facing and draft a response we can send to Zendesk in one click.
GPT-5.6 Sol worked for just under seven minutes. The result is a Draft Reply button on every ticket's detail page. Click it, confirm, and an agent goes off through Zendesk, HubSpot, the production database, and Gmail, then comes back with two things: a brief of what the customer is actually facing, and a drafted response. One more click and the reply is live on the Zendesk ticket.
The second half of the demo matters just as much. The first version of the response interface was not quite right, so the fix was another message: put the response interface in its own tab in the detail view. The app rebuilt around the feedback. When the interface is software you described into existence, iteration is a sentence, not a sprint.
What the agent inherits
The reason this beats a chat window comes down to what the agent starts out knowing.
It inherits the app's connections. The support desk was already authorized against Zendesk, HubSpot, the database, and Gmail. The embedded agent uses the same connections. Nobody re-authenticates anything, and there is no second copy of your credentials living in a bot.
It inherits the record on screen. Launch the agent from ticket #27 and it starts with ticket #27. There is no pasting thread history into a prompt or explaining which customer you mean. The context you would have spent five minutes assembling for a chatbot is the starting state.
It inherits the person. Every run records who launched it. Share the app with your team and the whole team gets the agent, running through the owner's connections, with no per-seat setup. Live run status streams to everyone in the app, and if an agent hits a question it cannot answer alone, the app shows a Needs input state until a human weighs in.
And because an embedded agent is a real agent rather than a widget, the whole runtime comes with it: full run history in the app's Agents tab, editable instructions, model choice, and a confirmation step before every launch.
Five patterns worth stealing
The support desk is one instance of a pattern: an interface your team already works in, with agents parked at the exact spots where the work starts. Some versions of it we expect to see a lot of:
- Support desks that answer. The demo's shape. A queue, a brief, a drafted reply, one click to send. Service desk benchmarks put an agent-handled ticket at about $45, three times the cost of a self-service resolution; a drafted reply that starts from full context attacks the expensive part of that number, the twenty minutes of digging before anyone types.
- A research button in the CRM. A table of thin lead records, and on each row a button that sends an agent off to fill the record in, summarize what it found, and suggest an angle. Selection is the input; the enriched row is the output.
- Dashboards that investigate. An anomaly list where each entry carries an Investigate button. Instead of a chart that tells you something is wrong, an agent that pulls the relevant records and reports back why.
- A drop box that returns finished documents. Upload the messy version, get back the house version. The agent does the restructuring; the interface holds the queue and the results.
- Approval flows with a human at the hinge. The agent proposes the refund, the reply, or the change, then pauses. A person reviews it inside the app and approves. The agent acts. This is the pattern that makes automation trustworthy enough to touch money and customers.
One app can carry several of these at once, each launched from the place in the interface where its work begins.
This is also the direction enterprise software is already pointed. Gartner expects a third of enterprise applications to include agentic AI by 2028, up from less than 1% in 2024, with 15% of day-to-day work decisions made autonomously. The open question is who decides which of your tools get agents: your vendors' roadmaps, or you.
The build-versus-buy collapse
Systems like this are currently a consulting product. Published development guides put custom agent builds at $20,000 for a simple agent to $500,000 and beyond for multi-agent systems, with goal-based agents, the kind in the demo, quoted at $40,000 to $150,000. Read the line items in any of those guides and the pattern is consistent: the model is the cheap part. Data preparation, integrations, orchestration, and the interface are the bill.
Not every one of those engagements collapses into a prompt, and it would be dishonest to claim otherwise. But the floor has moved a long way. The support system in the video, interface plus agent plus the wiring between them, took about fifteen minutes on a standard subscription, built by describing it. The version of custom agent software that used to justify a six-figure statement of work is now an afternoon of iterating on your own tool, with the logic of your own business, against systems you already run.
The deeper difference is who gets to change it. A consulting build freezes the day the engagement ends. An app with embedded agents changes whenever someone on your team notices it should: the interface is a conversation away, and so are the agents inside it.
Live now
Embedded agents are available in every General Input workspace today. Open an app you have built, or build one first, then describe the agent in the chat panel next to it: where it should appear, what context it should gather, what it should produce. The written guide walks the whole path, and the video above shows it happening in real time.
Interfaces used to be where you kept track of the work. They are becoming where the work gets done.