Handing a design to an agent usually means pasting an image and hoping. Studio hands over a structured document instead, and the useful part of it is the parts that point back into your repository.

## What the agent receives

- **The screen's semantics**, not its markup: what each element is, how it is laid out, and how it responds, extracted from the design's own representation rather than scraped from rendered HTML.
- **The tokens it uses**, matched against the tokens that already exist in your project. Where a design variable corresponds to a code token, the handoff says so, so the agent writes your token name rather than a hex value that will be wrong the first time someone changes the theme.
- **Component bindings.** Where a design component corresponds to a component in your codebase, the binding carries the source path and how confident the match is. An agent that knows the button on this screen is `packages/ui/Button.tsx` writes an instance; one that does not writes a new button.
- **The node ids**, carried into the code. This is small and it pays twice: it makes a later fidelity comparison exact, and it makes an automated tap on that element unambiguous when the flow becomes a test.
- **The motion**, as the compiled CSS described in [Motion](/docs/design/motion).
- **The assets** the screen actually uses.

## Where unmatched components go

A binding that matched is a fact. A binding that did not is also information, and it is reported as such rather than dropped: these are the components this screen needs and your project does not have yet.

That turns a handoff into a work list instead of an argument about whether the implementation is faithful.

## The other direction

The same map works backwards. Studio can read the components and tokens that exist in your project, which is what lets a design be authored against what is really there, and what lets a code connect draft be generated for the components that correspond.