ETF Agent splits the system into three processes — Core API, Product API, and Background Worker. What that buys isn't speed; it's the ability to maintain the liveness conditions for front-end Q&A, subscription management, and background execution separately. Controlled tests show that during two API start/stop cycles, fund research that had already begun was still completed by the original Worker. But we still have no production data on latency, cost, or long-term reliability.
What this is
Previously, all three functions lived in a single API process. Deployment was simple, but it carried a practical problem: maintaining a management interface could take down already-confirmed follow-up research along with it, and a background execution error could make ordinary Q&A unavailable as well.
After the split, the Core API handles sessions and front-end research, the Product API handles scheduled definitions, pausing and cancellation, and the Background Worker handles due tasks, recovery, and notifications. When front-end requests queue up, background tasks that haven't started yet yield model capacity; tasks already running are not preempted.
What needs to be distinguished: splitting processes is not the same as splitting business authority. Task claiming, run authorization, budget, report bodies, and notification receipts are still handled by the existing protocol and database. This did not produce three mutually synchronized business systems.
Industry view
We believe this represents an important engineering shift for Agent products, moving from "can complete tasks" to "can honor commitments across time." Once a user confirms automatic research after the daily close, the system must not only execute it once — it must continue the task through partial restarts, preserving results, sources, and history.
But the evidence for this rework remains thin. Testing covered only same-host processes, an isolated PostgreSQL, and synthetic models; it does not answer questions about latency, cost, failure rates, or operational burden in a real production environment. The three hosts still share a database and model service, so a Provider outage can still hit multiple chains at once. A lease expiring does not mean the old execution process has actually stopped, and a local port being alive does not mean the whole product is available.
So a more reasonable architecture is not the same as a proven better economics. For most single-shot Q&A applications with no long-running background tasks, three processes may only add deployment, monitoring, and troubleshooting cost. The isolation pays off more readily when there are subscriptions, continuous research, or scheduled delivery requirements.
Impact on regular people
For enterprise IT: system deployment can go from a single entry point to multiple ones, and the blast radius of an interface failure may narrow — but monitoring, version compatibility, and fault isolation work all increase. Before adopting it, confirm first whether the business actually has background tasks that must keep running.
For individual professionals: research, monitoring, and report generation have a chance to keep running while a management page is maintained or ordinary Q&A restarts. That said, this is still not a guarantee of unattended reliability; critical processes must retain result verification and human review.
For the consumer market: AI assistants may deliver scheduled reminders, continuous tracking, and periodic reports more reliably. But the first improvement consumers will see is "tasks don't get interrupted," not noticeably faster answers; the real value still depends on data quality and whether subsequent delivery is dependable.