Outline — Harness engineering beyond code

Speaker

Marc Sloan, product team at Tessl. Works on skills and evals — "the tools that keep agent context trustworthy." Previously Senior PM on Figma Dev Mode, focused on design system context in Code Connect. Before that, founded Context Scout (browser-based web search agent) based on his PhD at UCL on context-driven information retrieval.

Participants / addressees mentioned

• Marc Sloan (speaker)
• One audience member who asks a question in Q&A (unnamed in transcript)
• Conference: Tessl DevCon, day 2 opening
• The Tessl product is referenced repeatedly ("tessla" / "Tessl"); "Tessl.io start agent" mentioned as a forthcoming/teased capability

Abstract (as provided by speaker for the session)

The next layer of the agent harness is the product and design context outside the codebase. Agent harnesses have matured fast — Skills, AGENTS.md, Cursor rules, Claude skills — and have settled on the pattern of portable, versioned files in the repo that load on demand. This works for code but not for product, design, or business context that lives in Figma, Notion, Confluence, Linear. Baking it into a skill doesn't work because the source evolves independently; pulling it at runtime via MCP introduces drift in evals and versioning. The harness will need an intermediary layer. Design system teams (e.g. Figma's Code Connect) have been doing this work for years.

Thesis (synthesis)

The agent harness has converged on a good answer for context that lives in the repo, but the most important context — the product decisions, design system, and business constraints originating with PMs, designers, and execs — lives in third-party tools by design and will keep doing so. Neither baking-into-skills nor live-MCP-at-runtime is sufficient on its own: skills go stale, and MCP undermines evals. The next frontier of the harness is the intermediary layer between the codebase and those external sources of truth, and the field can borrow heavily from design system teams who've been doing this reconciliation work manually for years.

Section TOC

1. Intro and framing — "non-developers at a developer conference"; the shift from spec → context → harness engineering.
2. Worked example part 1: the export button — the agent ships the feature, but uses a generic React button instead of the design system's export button component, missing baked-in accessibility and async interaction patterns.
3. Where product/design context fits — the harness wraps the code base; product/design context sits outside the harness, in third-party tools, and the codebase is blind to it.
4. Challenge 1: it lives outside the code base.
5. Worked example part 2: drift — team mirrors Figma into Storybook; new enterprise deal brings new accessibility requirements; Notion and Figma update, codebase falls out of sync.
6. Challenge 2: drift in both directions — also code → design, as agents create components designers don't know about.
7. MCP as the obvious-but-incomplete answer — live third-party connection introduces availability, rate-limit, and eval-stability problems; product/design context has no canonical "done" state.
8. Lessons from Figma Dev Mode / Code Connect:
   • Dedicated maintenance teams exist for the design-code bridge.
   • Sometimes it's not desirable to keep the two fully in sync.
   • Business/IP constraints — Figma was "very protective of its design system IP" and didn't want to "give away the keys to the house."
9. Three (plus a sneaky fourth) directions the harness might evolve:
   1. Third-party tools opening up further (MCP servers, APIs, CLIs — with monetization).
   2. An intermediary agent between third-party context and the harness agent, building on the maintenance-team pattern.
   3. The external context gets swallowed into the repo, where it can be managed/versioned/evaluated.
   4. (Sneaky fourth) Each role gets its own agent and harness, and the harnesses talk to each other.
10. Worked example part 3: PM-driven, no developer — PM uses Granola + Claude Code + personal skills to file a Linear ticket and ship a feature, unaware that the export was hidden originally for architectural/cost reasons; the PM-skills are themselves outside the repo and unversioned.
11. Closing — product and design context is critically important for coding agents; lots of progress expected in next 6–12 months.
12. Q&A — one audience question about where to draw the line on what context to feed in.

Terminology glossary (definitions as Marc gave them)

• Harness engineering — the next stage after "context engineering"; the tooling layer that wraps the codebase and contains "skills, evaluations, hooks policies, all this other stuff."
• Skills — markdown-file context that "can live alongside the code that's described … lives within the repo, that it's managed, it's [versioned] and can be subject to evaluations and tests." Marc says he doesn't "need to convince anybody here of the value of skills."
• Code Connect — a Figma feature Marc worked on that "explicitly allowed design system teams to connect the design components in their design system with their equivalent in the code base."
• Dev Mode — "a feature in Figma which allows the designers to hand designs off to developers," giving developers "lots of great context about the designs."
• Product and design context — context that "by its nature lives outside of the code base" and "by its nature falls out of sync with the code base over time."

Named frameworks / concepts

• Harness as a wrapping layer — mental model: code at the centre; harness (skills, evals, hooks, policies) wrapping the code; product/design context wrapping the harness from outside, in third-party tools.
• Two challenges of product/design context:
  1. It lives outside the code base.
  2. It falls out of sync with the code base in both directions (design → code drift, and code → design drift as agents create new components).
• Why MCP alone isn't enough — live connection means: third-party availability risk; evals depend on constantly-changing external state; "there's never really a definition of done there."
• Three lessons from Code Connect:
  1. The bridge requires dedicated maintenance — "in enterprises there are entire teams [whose] sole job is to make sure that that connection is up to date."
  2. Sometimes full sync isn't even desirable; the job is "to make sure the status quo is functional."
  3. Business/IP constraints shape what can be exposed.
• Three (+1) evolution directions for the harness:
  1. Third-party tools open up further.
  2. Intermediary agent maintains the bridge.
  3. External context gets swallowed into the repo.
  4. Per-role harnesses (PM, designer, dev) that talk to each other.

Open questions / not covered

• Marc does not prescribe a specific technical design for the intermediary layer — he explicitly says "it's not clear which direction these things are going to go in."
• He does not give concrete details about Tessl's roadmap for this beyond the teased "Tessl.io start agent."
• He does not discuss CRM / customer-data context in any depth despite naming it — design system context is by far the dominant worked example.
• He does not address security, permissions, or auth boundaries for cross-tool agents.
• He does not give specific eval techniques for product/design context — only that "we need a set of evals to make sure that our agent is actually being boosted by that context."
• He does not name specific competitor tools or other companies' approaches beyond Figma (Notion, Linear, Confluence, CRMs are mentioned only as categories).
• The Q&A is short — only one question is captured before time runs out.