June 2026: Public APIs and agent-operated workflows
June's selected evidence moves beyond operating the canvas directly: a public-API mobile demonstration and an MCP beta describe new ways to invoke Comfy workflows. The important review boundary is what an application or agent can do on a user's behalf, and what evidence survives the run.
Dated announcements
On 22 June, Matt Miller described a native mobile app built on the public Cloud API. The post explicitly frames the example as lightly tested, not a hardened product, and reports a 12 June TestFlight release. Comfy: public-API mobile prototype (2026-06-22; first-person company demonstration).
On 29 June, Jo Zhang and Matt Miller announced Comfy MCP public beta, including workflow building, editing, execution and discovery through agent clients. The post also introduced beta CLI resources and a skills repository. Comfy: MCP public beta (2026-06-29; company announcement).
Funding and valuation status
No additional financing announcement is established for this month by the reviewed sources. This is not proof that no financing occurred. See the dated funding register; past totals and valuations are not new monthly raises.
What this changes: editorial analysis
Our interpretation is a shift in interface distribution: the same underlying workflow can be reached through a graph editor, a purpose-built app or an agent. That can reduce repeated setup, but it also makes authorisation and traceability more important. Neither an API example nor a beta announcement establishes that every client, workflow or permission boundary has been independently tested.
Treat the user instruction, generated workflow and executed job as separate records. An agent may correctly understand the intended task yet choose an unsupported node or an unintended execution route. Before a paid or sensitive run, inspect the proposed graph and the destination of inputs. Preserve the accepted version so subsequent edits can be compared rather than silently replacing the experiment.
A repeatable interface does not imply bit-identical output. Hosted model changes, dependency changes and execution conditions can affect results. Decide whether the handoff requires the same file, comparable quality or merely a successful run, then test that property. The beta status and the prototype's own testing disclaimer belong in the evidence record rather than disappearing from a promotional summary.
Proposed verification scaffold, not executed tests
- Start with non-sensitive inputs and the minimum account permissions required for the task. Set an explicit spending boundary and obtain approval before an agent installs software, changes a workflow dependency or sends a new class of input to a provider.
- Record the requested action, graph revision, selected execution route and job identifier. Confirm that the saved output corresponds to that job. A natural-language success message is not a substitute for retrieving the actual file and checking it.
- Test an interrupted or rejected job as well as a successful one. Verify whether a retry duplicates work or charges and whether another operator can recover the workflow. Keep test failures visible instead of counting only the demonstrations that completed.
Record the environment, exact versions, permitted inputs, output location, failures and acceptance decision. No pass result is implied by this checklist. Use the workflow evidence guide and measurement method for the corresponding record formats.
Open questions and next review
- Which actions need a human approval step in this specific environment?
- What changes between the beta interface and the currently documented client?
- Can the complete graph and accepted output be recovered without the original conversation?