September 2026: Provider choice and production handover
Through 29 September, Comfy's selected announcements address two production problems: choosing an execution provider through a common API, and transferring practical workflow knowledge into a team. This is a provisional September report, not a completed review of events that may occur on 30 September.
Dated announcements
Doug Hogan's 4 September post describes Forward Deployed Creatives: validating a use case, building in the customer's environment and training the team to own the workflows. The offer centres on operational handover rather than a finished benchmark. Comfy: Forward Deployed Creatives (2026-09-04; company service announcement).
Comfy launched Router on 23 September with explicit provider selection. The post says an unavailable named provider fails rather than being silently substituted. It describes workflow deployment through the same SDK as forthcoming; that roadmap is not treated as already shipped here. Comfy: Router launch (2026-09-23; 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 that provider choice and internal ownership are complementary. One concerns who executes a job; the other concerns who can maintain its workflow. A common API can reduce integration work without making providers interchangeable. Embedded help can improve a handoff without proving that a team is self-sufficient after the engagement. Both claims need their own acceptance evidence.
Before comparing routes, freeze the model, input and required output. Provider availability, supported controls and processing terms can differ even when a model name matches. Test failure handling explicitly and preserve the provider reported for each job. Do not market a manually selected alternative as automatic failover, or assume that a queue retry changes the provider.
For an implementation engagement, define an exit test before work begins. A person who did not author the graph should be able to explain its dependencies, modify an approved input, recover a failure and locate the output. Keep support-dependent steps visible. A visually impressive demonstration is not enough evidence that the client can maintain the system without the original specialist.
Proposed verification scaffold, not executed tests
- Use permitted sample inputs to verify the selected provider, job status and retrieved file. Include an unavailable route or controlled failure where safe, and record the observed behaviour rather than assuming the marketing description is an independent test.
- Have a different team member follow the handover notes in a recoverable environment. Check model identities, node versions, permissions and the rollback point. Record exactly where assistance is still needed and make that a training action.
- For the month-end close, review official announcements dated 30 September after that date, check whether roadmap items actually shipped, and append any correction with its own source date. Do not change this report's cutoff until that review has occurred.
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 Router model/provider pairs support the controls required by the real workload?
- What evidence demonstrates independent team ownership after an engagement?
- No new September financing is established by these reviewed sources; the April valuation is historical, not a fresh September mark.