When one input and one output isn't the shape of the problem
One of the Functional API's most powerful features: combining different data types and producing multiple predictions in a single model. Plenty of real problems are natively multi-input or multi-output — a support ticket has a title, a body, and tags (three different feature spaces), and you may want to predict both its priority and its routing department at once. Forcing that into a single-input, single-output model means either training three separate models or flattening everything into one vector and losing the structure.
The Code block shows the canonical shape: one branch per input, each processed by its own layers, merged with layers.concatenate, then split into one head per output. Every input and output gets a name=, which is what lets you pass data and losses as dictionaries instead of brittle positional lists.
Multi-task isn't free
Multiple heads share the trunk, so the gradients from each output flow back through the same merged features — that shared representation is the whole point (it's why multi-task models often generalize better than separate ones). But it also means the heads compete: if one loss is numerically larger, it dominates training. That's what loss_weights is for at compile time — scale each loss so no single head drowns out the rest. Start with equal weights, watch the per-output losses, and rebalance only if one stalls.