Proposal: document AgentsKit as a portable Supabase pgvector adapter for JavaScript agents

Problem JavaScript developers building agents with Supabase often have to assemble three separate pieces themselves: a vector-memory contract, PostgREST mutations, and a pgvector search RPC. The easy shortcut is a generic SQL-execution RPC, but exposing caller-provided SQL—especially through a security definer function—is not a pattern I think the Supabase community should encourage. There is also a portability problem: if application code is written directly around one vector provider's API, moving between Supabase, local pgvector, or another managed backend becomes a rewrite instead of a configuration change. What is already implemented AgentsKit is an open-source, modular agent toolkit for JavaScript. Its @agentskit/memory package now includes a Supabase adapter behind the same VectorMemory contract used by its other storage backends. The Supabase path intentionally uses: • direct supabase.from(table).upsert(...) for writes; • direct delete().in('id'…