# Why Components Why split an orchestration into components: one big script cannot tell you which part made the answers worse. - Page: https://perceivo.ai/university/comp-01-why-components - JSON: https://perceivo.ai/registry/film/comp-01-why-components.json - Kind: film - Revision: 3 (published 2026-10-18, produced 2026-10-15) - Previous revision 1 (published 2026-10-07): https://perceivo.ai/registry/film/comp-01-why-components/r1.json - Previous revision 2 (published 2026-10-10): https://perceivo.ai/registry/film/comp-01-why-components/r2.json - SDK version: none ## Validation - SDK: not applicable (Concept film; no component or orchestration is offered for download) - Platform: not applicable (Concept film; no component or orchestration is offered for download) ## Transcript [0:00] Introduction to Components, Episode 1: Why Components [0:06] Welcome to our Introduction to Components series. [0:09] Before we ask what a component is, let's ask why you'd bother with one at all. [0:15] In this orchestration, we have a stream of steps, executed one after another, from a start to an end. [0:23] These components are deterministic, meaning, under normal operations, their behavior is 100% predictable. [0:31] Where things become interesting is when some of your components behave in ways that are not entirely predictable. [0:38] Things like models and agents. [0:40] Probabilistic components present interesting design challenges. [0:45] But let's start by taking the complexity away. [0:49] The simplest orchestration that runs: a Start, an End, and one component in between. [0:57] Give that one component a script, and put everything in it. [1:01] Build the context, call a search tool, call the model, return the answer. [1:07] And it runs. [1:08] Straightforward. [1:10] Simple. [1:11] One box, one script. [1:15] But now, some of your answers start getting worse. [1:19] Which part caused it? [1:21] The context? [1:22] The search? [1:22] The model? [1:24] You can't tell. [1:25] The run reports one result, for one box. [1:29] And trying two ways of building the context, or three different models, means copying the whole script and editing it by hand. [1:39] With ordinary code, that's an inconvenience. [1:43] With AI, it's flying blind. [1:47] A model that performs well under one set of conditions can falter under another. [1:52] Operators need to find the source of that variance, not just notice it. [1:58] So we split the script, the same way a programmer refactors helper functions out of a long block. [2:04] A context builder, a search tool, and the model call, each its own component. [2:11] Now every run shows how each part did, on its own. [2:16] Swap the model, and only one part's numbers move. [2:20] Now you know where the variance came from. [2:24] This is why every component plugs in through a typed contract: a declared shape for what goes in, and what comes out. [2:33] Two components can do the same job in different ways. [2:37] Same contract, so either one drops into the same place. [2:42] Which one is better is a question for benchmarking. [2:46] And because the swap changes nothing else, the comparison is fair. [2:51] Our Introduction to Capabilities series runs exactly that test. [2:56] That doesn't mean one component per helper function. [3:00] The small stuff stays inside a script. [3:03] Make a component where you want to see a part's performance, or swap it for another. [3:09] A well-architected orchestration explains more than how control flows. [3:14] It explains how components with variable performance are managed. [3:19] That's what the platform was built for, and it's why we break things into components. [3:25] Everything in this series is open source, with every example in the Perceivo SDK repository. [3:33] Next time, we open one up: what a component carries, and three ways to build one. [3:39] See you there.