Schema-valid AI jobs outside the TYPO3 request

A slow service does not belong in a web request

Putting an AI call in a controller looks straightforward: collect input, call the model, store the response. In operation, that is the wrong boundary. The runtime is not reliably short, an external service can be temporarily unavailable, and a syntactically valid result can still be unsuitable. When all of that happens inside a TYPO3 request, an editorial aid becomes a hanging page with an ambiguous failure state.

On the Homepage, AI work therefore starts as a bounded database job rather than a long request. The request only confirms that the work has been accepted. A single worker processes it outside the HTTP lifetime. That adds a little machinery, but separates three different truths: what the user requested, what the worker is doing, and which result TYPO3 is actually allowed to persist.

The contract is smaller than the prompt

Free-form text is useful for describing the task but unsuitable as a return contract. The worker sends a JSON Schema with the prompt. The remote run may return only an object with the expected properties, and additional fields are rejected. Size and time limits keep a small editorial job from turning into an unbounded process.

That first validation is not enough. A schema proves shape, not meaning. The application checks the response again: does it contain exactly the missing fields, do values fit their length and type constraints, and do they belong to this record? Only then does TYPO3 write. Images add file-type, dimension, and size checks. A file named by a model is not automatically an acceptable public asset.

The double contract makes failures easier to locate. An invalid remote result does not become a half-written record. An unavailable runtime does not become a successful Scheduler execution. An editorial draft stays a draft until a human reviews it.

A worker needs honest states

Asynchronous must not mean invisible. Every job needs a state, bounded retries, and a durable failure message. The Homepage worker runs the TYPO3 Scheduler at regular intervals; translation, blog suggestions, and metadata remain separate small workflows. Each execution handles only its intended amount instead of leaving a large, unclear batch after a failure.

That also improves the interface. It can distinguish waiting, processing, and failed work instead of presenting every delay as an endless spinner. A good asynchronous interface does not promise that external work finishes instantly. It promises that the state remains understandable.

What a schema does not solve

A strict schema cannot prevent a false claim and does not replace editorial responsibility. Current public facts may require bounded research, while private data still does not belong in the prompt. Translations need language review, published writing needs approval, and failed jobs need a clear recovery path.

The central decision is therefore not the particular model. It is the system boundary: the web request accepts work, the worker executes it within limits, the schema constrains its shape, and TYPO3 independently decides what may be stored and eventually published. AI remains a tool inside the system instead of becoming the system itself.