Dawn already connects to repositories, ticket systems, wikis, and cloud storage. A lot of the decisions that shape a product do not live in any of those. They live in Figma files, component libraries, design tokens, and the Framer project that defines how the marketing site is actually put together.
Until now, that context stayed outside Dawn. You could ask an agent for a UI idea, a mockup, or a lightweight prototype, but it had to work from text instructions and whatever product context was already in the workspace. The visual system had to be re-described every time.
This release adds first-class support for two design tools. Link your Figma files or Framer project to a workspace, assign them to agents, and those agents can read from them like any other connected source.
Figma
Connecting Figma follows the same model as other Dawn integrations. The workspace owner adds the connection, then points Dawn at the specific file or component they want available. Instead of exposing the entire Figma workspace, you paste the file URL or the component node URL you actually care about, and Dawn discovers the file, the relevant component, and the variable collections tied to it.
That works well for teams that already know which file matters. A design lead can link the core component library. A product team can link the specific flow they are iterating on. An agent producing HTML prototypes can stay closer to the naming, structure, and reusable pieces the team has already built.
It is also useful when a request starts from a file. If someone drops a Figma link into a conversation and asks for a variation, an agent with access to the linked file can inspect the component, read the variable collection, and produce work that lines up with the design system instead of inventing a new one next to it.
Framer
Framer works differently because the unit of context is the project, not a pasted file. Dawn connects to a real Framer project and discovers what is already there: the site, its pages, and the reusable styles that support them.
That matters when the product or marketing surface is already being shaped in Framer. An agent can look at the current page structure, read the style names the project uses, and stay closer to the real project language when suggesting changes or drafting something new. The Framer project stops being an external reference and becomes part of the context Dawn works from.
For teams using Framer as more than a publishing tool, that is a meaningful difference. Page names, section structure, and the styles a team has already named all become things an agent can reason about directly.
What This Changes Day to Day
The practical effect is better grounding for any request that sits near design.
A product manager can ask for a prototype that feels like the existing interface instead of describing the design language from scratch. A designer can ask Dawn to inspect a component before proposing a variation. A marketing team can connect the Framer project that already drives the site and use it as context for new page ideas or revisions.
It is also useful outside pure design work. Support, product, and operations teams often need to understand what the UI actually looks like today. Once the relevant Figma or Framer sources are linked, an agent has a better chance of answering those questions with something grounded rather than generic.
Paired with HTML artifacts, the loop gets shorter still. Ask for a mockup that uses the linked design system, preview it in the same thread, and iterate until it fits. The visual language the agent is drawing from is the one your team is already shipping.
Scoping What Agents Can See
Both integrations give you control over what is exposed. With Figma, you link the specific files and components you want available — not everything the connected account can see. With Framer, you connect the project that should be in scope and leave the rest alone.
On top of that, linked sources are assigned to specific agents. A UI prototype agent can have the design system sources it needs, while a release-notes agent does not. That scoping is per-agent, so different agents in the same workspace can have different design views.
Design context can also be introduced incrementally. Start with one file, one component library, or one Framer project, and expand only when it proves useful. You do not have to open the door to an entire design workspace just because one agent needs to read one file.
Getting Started
The setup guides cover the exact connection shape Dawn expects today:
The pattern is the same in both cases: create the connection, discover sources, link only what you want available, and assign those sources to the agents that should use them. Once that is in place, Dawn can work from the product language your team already designed instead of guessing at it.