Pedro Rodrigues · 13:22 "The bottleneck isn't context anymore — it's guidance. The tools are in place. What's missing is the skill that tells the agent the right way to operate."
What Pedro Rodrigues presented at AI Engineer Europe 2026 was the launch of the official Supabase Agent Skill, plus three months of design lessons summed up as "I haven't spent this much time on a single document since my master's thesis." The title was originally submitted as "MCP vs Skills," but with the industry debate now settled around the consensus that "the two play different roles," he swapped it for "how to combine the two to close the context gap" — a switch that's symbolic of the timeline itself.
Why this talk belongs on MEMEX is clear. Six months after Anthropic's official launch of the concept of skills (Barry Zhang and Mahesh Murag's "Don't Build Agents, Build Skills Instead" in October 2025), this is the first serious case of a non-frontier-lab company implementing a skill for its own product. OpenAI has also been weighing in on protocol design with Nick Cooper's "use both MCP and CLI", but Pedro's account is on-the-ground knowledge from the implementation side: how to repackage your product docs for an agent.
Agents are smart, but they don't know your product
Pedro's problem statement is simple. "Agents are smart enough. They handle everyday mundane tasks on their own. The problem is when they encounter something that didn't exist at training time, or was updated after training — your product, for example. Then the agent needs the right guidance."
Concretely, with Supabase: agents miss Row-Level Security (RLS) A PostgreSQL feature that controls access at the row level rather than the table level. For instance, you can enforce 'each user can only see their own rows' as a SQL-level constraint, keyed by user_id. Practically essential for multi-tenant SaaS, and one of the major reasons Supabase is popular as a backend. There's a trap: when you build a VIEW on top of a table with RLS enabled, by default the VIEW bypasses RLS — to prevent this, you have to explicitly pass `security_invoker = true`. pitfalls, run on stale information from old training data, and they are "lazy and stubborn about admitting what they don't know" — they don't go fetch new information. All of this can be sidestepped if the agent has guidance for the specific workflow. That's the starting point for Supabase Skill.
Pedro's live example: in a collaborative app, ask the agent "create a new SQL view on top of a table with RLS enabled." In PostgreSQL, if you create a view on top without explicitly setting security_invoker = true, the view bypasses RLS, exposing data that shouldn't be visible. An agent with only MCP (Claude Sonnet 4.6) falls into this trap. Given MCP plus Skill, the same agent implements it correctly and safely. The tools (MCP) are identical — what changes is the presence of guidance.
Three principles of skill design — from three months of iteration
Pedro's three principles for skill authoring are a reference point for any team about to write a skill for its own product.
Principle 1: don't duplicate information — point at the official docs
"Treat the skill as documentation for yourself. You wouldn't duplicate your own documentation, right?" Pedro says. With the product's official documentation already in place, copying the same information into the skill is the start of a maintenance hellscape. The alternative is to instruct the agent — very stubbornly — to search the web for the latest documentation before answering. Models default to leaning on training data, so the instruction has to be repeated.
Supabase recently announced an experimental move: exposing the docs over SSH An experimental initiative Supabase announced just before AI Engineer Europe 2026. The official documentation is made accessible to agents over the SSH protocol. The hypothesis: because LLMs are very comfortable with filesystems and Linux-based tools, exposing the docs as a structure that can be 'navigated as a remote filesystem' makes it easier for the agent to go and fetch information than a general web search. Pedro asked for open feedback at AI Engineer Europe, calling it 'still experimental.' . LLMs are very familiar with filesystems and Linux-based tools, so the hypothesis is that exposing docs as a structure that can be navigated as a remote filesystem makes it easier for an agent to fetch information than web search would. It's experimental for now, but it's worth watching as an attempt to reshape the web-era assumption of "documentation as HTML" into something that suits the agent era.
Principle 2: anything that can be skipped will be skipped
The most practical point in the talk. "Agents treat external information retrieval and tool calling as expensive, so by default they fall back on training data. The same thing happens with reference files." What Supabase verified: agents read what's in the body of skill.md, but only load reference files lazily. And after loading one reference file, the probability they load another approaches zero. Split into three or four and it's out of the question.
The countermeasure: information you absolutely don't want the agent to miss (in Supabase's case, the security checklist) goes directly into skill.md, not into a reference file. "I initially split the security checklist out into a reference file, but the agent usually missed it, so I moved it back into skill.md." A field correction to Anthropic's progressive disclosure idea — a reality check that "some information is unsafe to leave on a progressively-loaded path."
Principle 3: be opinionated
"You know your product best. You know how users should use it — or you ought to. Don't be afraid to strongly nudge the agent toward what you consider the most effective workflow." Many skill authors hesitate here, worrying that they're stripping the agent of autonomy, and ending up with vague instructions. In Pedro's experience, the more opinionated the workflow embedded in the skill, the more stable the agent's output.
A specific Supabase example: database schema management. (1) Run DDL freely in dev/staging → (2) find and fix issues via Supabase Advisor (security / performance checks) → (3) only then create a migration file. This is opinionated, and at odds with the intuitive workflow of "create a migration file with every change," but it's the flow Supabase has empirically concluded is best. Encoding it in the skill prevents the agent from prematurely mass-producing migration files.
"An era when we test Markdown files" — verifying skills with eval
As an emblem of the moment, Pedro highlights: "We're now living in an era where you can test documentation. A few years ago this would have been bonkers." A skill is more than documentation — it's an executable specification that changes the agent's behavior, so it can be tested in CI.
Supabase's eval setup:
- Six specific scenarios — a task set modeled on different situations in an ongoing Supabase project
- Four agents across two vendors — Opus 4.6 and Sonnet 4.6 on Claude Code, GPT 5.4 and GPT 5.4 Mini on Codex
- Three test conditions — (1) baseline (no MCP, no skill), (2) MCP only, (3) MCP plus Skill
- Methodology — a 4-graded test completeness score, run on BrainTrust A SaaS platform for LLM eval. Centralizes trace collection, eval execution, and regression detection. BrainTrust sponsored AI Engineer Europe 2026, and the Supabase skill eval was also run on BrainTrust. A direct competitor of Arize Phoenix, with BrainTrust leaning more SaaS-side and Phoenix more open-source-side.
The result, across every model: MCP plus Skill beat the other two conditions. "The tools were already there, the MCP server already existed. What was needed was the right guidance for how to operate Supabase." This resonates with Laurie Voss (Arize) on Ship Real Agents — "production agent reliability depends on the eval architecture." The same industry consensus appears in Vincent Koc (Comet) on Malleable Evals — "combine multiple evaluation methods." Pedro's numbers operationalize this consensus across a 4 model × 6 scenario × 3 condition grid.
The unsolved problem — skill distribution and registries
An important question from Q&A: "How do you distribute skills within an organization?" Pedro's answer is direct: "This is currently the biggest constraint on skills." The industry is in the middle of a battle over distribution formats — Vercel's skills package, model-vendor plug-in formats (.clot, .cursor, etc.) all coexist. "There's no standard yet."
Inside Supabase, skills ship in the repository. In open-source repos they're naturally discoverable; in closed repos, only those with access can use them. "Looking at how other companies distribute their skills, everyone is converging on putting them directly in the repo." The same problem as Nick Cooper (OpenAI) on MCP discovery — the identity / discovery layer for agents to find what they need from a flood of tools is still unbuilt, an industry homework problem.
Editorial reading — skill as a reshape of product docs
Three angles for taking this talk into MEMEX.
(1) Skills as a new competitive axis for B2B products. Differentiation for developer-facing products used to live in "good API" and "good docs." In the agent era, "does it provide an opinionated skill for agents" enters as a new axis. With Supabase moving first, competitors like Firebase, Neon, and PlanetScale stand at the fork: ship a skill, or be left behind. The pace of the industry dynamic that started with Anthropic's official skills announcement just six months ago is visible here.
(2) Turning documentation from "reading material" into "an executable specification." Pedro's phrasing — "an era when we test Markdown" — is a sign that the boundary between docs, tests, and implementation is dissolving in the agent era. A skill is Markdown but it's tested by eval and it determines production agent behavior. Documentation team work may shift into the space between DevRel and SRE.
(3) The field knowledge that "stubborn instruction is required." Pedro's points — "agents default to training data," "anything that can be skipped will be skipped" — are a reality check on agent design that continues from the prompt-engineering era. The same undertone appears in agentic search and context engineering and in Granola's "you cannot one-shot it" finding. Agents are smart but lazy, so guidance has to be spoon-fed to land.
Video outline
- (00:00) Self-introduction, the problem framing now that the MCP vs Skills debate is settled
- (01:50) Agents are smart, but they don't know your product
- (02:30) The Supabase RLS-bypass example — MCP only vs MCP plus Skill
- (05:09) Supabase Agent Skill general release announcement (live tweet)
- (05:56) Principle 1 — don't duplicate, point at the docs
- (06:34) The experiment of exposing docs over SSH
- (07:34) Principle 2 — anything skippable will be skipped
- (09:07) Principle 3 — be opinionated, the database schema management example
- (10:50) Testing the skill with eval — 4 models × 6 scenarios × 3 conditions
- (12:36) Result — MCP plus Skill wins in every condition
- (13:22) Conclusion — the bottleneck isn't context, it's guidance
- (14:00) Installation, Supabase blog post live
- (15:00 to 18:26) Q&A — vector DB / distribution / registry problem