Where agent-built tools should live

A tool someone prompted into existence answers four questions whether or not anyone asked them. Where does it run? Who can see what it collects? Who knows what it did? Who keeps it working when the person who prompted it moves to another team?

Built wherever the agent happened to be pointed, the answers are usually a personal cloud account, whoever holds the password, nobody, and nobody. The model did its job; nobody decided where the tool should live. That gap is one reason so many agent projects stall: Gartner expects more than 40 percent of agentic AI projects to be canceled by the end of 2027, and names inadequate risk controls among the causes.

On Plexara the tool is an automation, the same kind of governed script the agent already writes for reports and syncs, with versions, tests that replay recorded runs, and plain-language approval when its behavior changes. The difference is what can start it. Beyond running on demand and on a schedule, an automation can now run once for each event that arrives and answer requests at its own address.

The split of responsibility is deliberate. The agent writes the form or the endpoint from a conversation. Publishing it, giving it an address on your deployment and deciding who may reach it, is an admin action. So is allowing a form to be embedded on an outside site. Nothing an agent builds becomes reachable from outside without a person choosing that.

Whatever arrives, a submission, a request, a webhook, an email, becomes a row your agent can query and join with the rest of your data, and can start the automation that handles it.

Describe what you need to collect, and the agent builds the form. It supports ten kinds of field, including files, and choices can be filled from live data at the moment the form opens, so a store picker always lists the stores you have today. The form gets a hosted page on your deployment, can sit inside a report or dashboard, and can be embedded on a site your admin allows. It follows the reader’s light or dark setting and works at phone width.

Spam is stopped before anything is kept: the form is signed so it cannot be altered, a hidden field catches bots that fill everything in, a submission made faster than a person could type is refused, and an admin can require a bot check, either the platform’s own or Cloudflare Turnstile or hCaptcha. Each accepted submission is written as a row before the person sees the confirmation, so nobody is told "thank you" for something that was not saved. Fields marked sensitive are encrypted one by one before they are stored. Only the form’s owner, admins, and automations running for roles named on the form can read them, and every reading is recorded.

The limits are worth stating plainly. There is no drag-and-drop builder; the agent builds the form. There is no conditional logic, no multi-page form, no payment collection, no themes, and no survey analytics beyond what you can query yourself. For a long marketing survey with branching, a dedicated form product is the better tool. For intake that should land next to the rest of your data, under your access rules, this is the better home.

An endpoint is an automation that answers HTTP requests at its own address: a lookup a partner system calls to check an order’s status, or a feed another system pulls on a schedule with an API key. An admin chooses who may call it, signed-in people and named API keys, anyone who passes a bot check, or anyone at all, and sets how often it may be called. Admin shows each endpoint’s requests, response times, and every refused request with the reason. Answers are data. An endpoint is not a place to host a web application, and a rich page comes from a form or a report instead.

A mailbox source reads a mailbox your team gives Plexara, and never changes anything in it. It keeps mail only from senders you approve, and only messages that pass the standard email authentication checks, so a forged sender is counted and dropped. Each kept email becomes a row and each attachment a searchable file. Pulling the invoice number out of the message is the automation’s job, written by the agent and tested like any other.

The part that makes these tools work as systems is how they start automations. Every stored submission, webhook delivery, or approved email starts one run of the automation that names its source, seconds after it is stored. A sender that retries a delivery does not cause a second run. The run happens after the row is written, so a slow automation never slows down the person or system that sent the event.

A run that fails tells its owner and is not repeated on its own, because it may already have written something. The next event still runs, and the row that failed is still in its table for anyone to look at.

Consider a retailer onboarding new suppliers. Today that is a form builder, a shared inbox, and someone retyping details into the ERP. On Plexara a buyer asks the agent for an onboarding form: company name, contact, tax ID marked sensitive, the categories they supply chosen from the live category list, and a file field for their insurance certificate. An admin publishes it with a bot check and allows it to be embedded on the supplier page of the company website.

Each submission lands as a row. The tax ID is stored encrypted. The certificate is saved as a file the agent can find. An automation named on the form’s source runs once for each submission: it checks the supplier against the existing vendor table, posts a summary to the purchasing channel in Slack, and writes the new supplier to a review table. The buyer asks the agent next week how many suppliers in garden products came through the form, and gets an answer from the same data, joined to sales.

Nothing in that example is a separate product. The form, the run, the channel, the data, and the record of who saw the tax ID live in one place Deasil operates.

This is consolidation of the small tools around your systems of record, not a replacement for those systems. Intake forms that today live in a form builder, catch-hooks in a workflow service, an email parser for a single vendor’s notices, and the little backend behind a request page are the kind of work that moves well, one at a time and usually when a renewal comes up. The CRM, the ERP, and the warehouse stay where they are.

The idea is in the air. Snowflake made endpoints that route outside HTTP requests into its integration flows generally available in October 2026, inside its own cloud. What Plexara adds is the rest of the home: any frontier model as the builder, every system you already run as the data, the knowledge your team has taught the platform, and review before anything an agent writes reaches production.

For how these automations stay healthy after launch, see automations you can leave running. For the wider picture, see Forms and Endpoints, Automations and Webhooks.