What this makes possible
Most agents are good at deciding what should happen next and much less reliable at reconstructing a specialist process while a user waits. A creator-built Edgaze workflow gives the agent a finished operating path: the prompts, models, tools, branches, input limits, and final result have already been designed and tested. The same published product can serve a person on its marketplace page, an application through the REST API, and an AI agent through Edgaze MCP, so the useful part of the system is maintained once instead of being copied into three integrations.
That changes the agent's job from improvising a workflow to choosing and operating one responsibly. It starts with the user's desired outcome, searches the marketplace in those words, and inspects a promising product before proposing execution. Inspection supplies the real field names, examples, price, and demo availability, which means the agent can ask only for information that is actually missing. Sign-in, wallet funding, and approval of a paid price stay visible to the user. Once accepted, the agent starts one durable run, waits at the interval returned by the service, and delivers readable text in the conversation or an Edgaze run URL when the result is a file, image, video, or other rich asset.
A marketplace is more useful than an uncurated tool pile
Giving an agent more tools does not automatically give it more useful capability. A large set of low-level actions forces the model to choose the right tool, infer the order, translate data between steps, recover from partial failure, and decide what counts as a finished answer—all inside the user's conversation. That is exactly where seemingly capable agents become inconsistent: the plan is rebuilt on every attempt, and small changes in context can produce a different sequence.
A published workflow compresses that operational knowledge into a product with a name, a specific job, a typed input contract, an immutable version, a visible price, and a deliberate result. The agent still decides whether the product fits the request, but it does not have to rediscover how to perform the underlying work. A research workflow, for example, can own its retrieval, ranking, synthesis, and output formatting while the agent concentrates on gathering the right brief and presenting the answer well.
This also creates a cleaner maintenance boundary. The creator can improve prompts, switch supported models, repair an integration, or publish a new version without asking every agent developer to reproduce the change in a tool definition. The agent calls a stable product identity and inspects the live contract before use. That is more dependable than hiding a long chain of instructions in a system prompt and hoping every client executes it the same way.
Selection and payment should be inspectable
An agent should be able to explain why it chose a workflow before it spends money or sends sensitive input. Edgaze separates discovery from execution for that reason. Search answers the broad question—what products appear relevant—while inspect returns the selected workflow's accepted fields, examples, access state, displayed price, and whether a demo is available. If there is no match, the correct behavior is to say so and continue with another method, not to invent a slug that sounds plausible.
The same discipline applies to input collection. The agent should reuse information the person already supplied, map it to the published schema, and ask only for required values that are still absent. Unknown keys and conflicting aliases should be treated as errors rather than silently ignored. This makes the run reproducible and gives the user a chance to notice when the requested data is too broad, too sensitive, or simply unrelated to what the workflow promises.
Commercial intent remains equally explicit. A zero wallet balance is a normal account state, not a failed installation. A free demo is available only when inspection says the product qualifies, and it runs the actual published workflow with the user's input without charging the wallet or paying the creator. A paid run should begin only after the agent has shown the current price and the user has chosen to proceed. Wallet funding belongs to the user's Edgaze account and does not require rebuilding or reconnecting the agent integration.
No invented workflow slugs or guessed input names. No paid run before the price and required inputs are known. No second agent-only copy of the workflow to maintain.
The run should outlive the conversation turn
Useful workflow products often take longer than a normal tool call. They may coordinate several models, fetch external pages, call third-party APIs, repeat work over a list, pause between steps, or produce a large media file. Edgaze gives each execution durable state, so the agent does not need to hold one browser tab or request open and pretend that silence means failure. It starts the run once, retains the run identifier and cursor, and uses watch until the service reports a terminal outcome.
Watching is intentionally different from retrying execution. When a watch returns no new output, the agent waits for the supplied polling interval and watches the same run again. It should not create a duplicate paid run for the same request. This distinction matters in real products, where network interruptions and long model latency are ordinary and where a repeated execution can create a second external action or charge.
Result presentation is part of the contract too. Text and markdown can be turned into a useful answer in the chat instead of dumping raw JSON. If the workflow sends an email, opens a ticket, or publishes a post, the agent can describe the action and include the confirmation data returned by the workflow. Images, video, files, and other media are better served through the durable Edgaze run URL, where the owner can view or download the output without forcing binary content through the conversation.
Give an agent its first workflow
The shortest responsible path is to connect the hosted server, verify that its five tools are present, and use a real request to test discovery before testing payment. This proves the client, authorization, product contract, and run lifecycle separately, so an empty wallet or an unsuitable search result is not mistaken for a broken connection.
Add https://mcp.edgaze.ai as a remote HTTP server in the AI client, complete the browser OAuth flow with the Edgaze account that should own the runs, and confirm that catalog, search, inspect, run, and watch are all available. Open connection guide. Give the agent an outcome rather than a guessed product slug. Let it browse the public catalog, stop honestly when search reports no match, and inspect one candidate's current input schema, displayed price, and demo state before asking you for data. Browse workflows.
For the first execution, follow catalog, search, inspect, run, and watch in order. Use the inspected field names, set a maximum accepted cost at or above the quoted price, and never create a second run merely because a watch call returned no new output. Follow the first-run guide. If inspection says a free demo is available, use it only when the user wants that path; it is a real run, not a canned preview. For paid work, add wallet funds after the exact price is known, then retry the intended run without reconnecting the MCP server. Understand MCP funding.