DEV Community: Papa

Familexyz: Giving AI Agents Persistent Memory with Cognee Cloud

Papa — Sat, 04 Jul 2026 15:23:15 +0000

Integrating Cognee Cloud's memory layer into FamilyXYZ — a multi-agent AI platform where five philosophy-inspired agents help families strengthen their relationships across Telegram and the web — and ended up filing a PR against Cognee itself.

TL;DR — 4 lessons from this integration:

When the docs are unclear, read the source. An "undocumented" endpoint we thought didn't exist actually did — we found it in the Cognee repo, not the docs.
The default search mode isn't always right for you. Switching from GRAPH_COMPLETION to CHUNKS cut an LLM call and seconds of latency out of every recall.
Graceful degradation is non-negotiable. A no-op fallback service meant the app kept working even with the memory layer fully disabled.
Fixing a bug taught us more than the docs did. We ended up contributing a PR (#3863) after tracing inconsistent error responses through the router source.

Details below.

The Problem

FamilyXYZ has five AI agents — Wisdom (Alain de Botton), Intimacy (Esther Perel & Gottman), Presence (Thich Nhat Hanh), Growth (James Clear & Carol Dweck), and Bridge (StoryCorps & bell hooks). Families interact with them via a Telegram bot and a web dashboard.

The agents were helpful in the moment, but they had no memory. A parent could tell the Wisdom agent about a difficult conversation with their teenager on Monday, and by Wednesday the agent had no idea that conversation ever happened. For a family wellness product, this is a fundamental gap — real relationships are built on accumulated context, not single interactions.

We needed persistent, per-user memory that:

Stored every conversation, check-in, and interaction
Could be queried for relevant context before each agent response
Supported enrichment (building a knowledge graph from raw text)
Allowed full data deletion (GDPR-style right to be forgotten)
Was optional — the app had to keep working if the memory service was down

Why Cognee Cloud

We evaluated several options: raw vector databases (Pinecone, Weaviate), LLM-native memory (Mem0), and Cognee. We chose Cognee Cloud for three reasons:

1. Knowledge graph, not just vectors. Cognee doesn't just embed text and do similarity search — it builds an actual knowledge graph with entities and relationships. When a user says "I argued with my partner Sarah about screen time," Cognee extracts the entities (user, Sarah, screen time) and relationships (argued_with, about). This means recall can find semantically related memories even without keyword overlap.

2. The lifecycle maps perfectly to agent memory. Cognee has four operations that map cleanly to what an agent memory layer needs:

remember() — ingest text, build the knowledge graph automatically
recall() — query the graph for relevant context
improve() — run enrichment on the existing graph
forget() — delete a user's entire memory

3. Managed cloud, no infrastructure. Cognee Cloud gives us a tenant-isolated instance with a REST API. No graph database to run, no embedding pipeline to maintain, no vector index to tune.

The Integration

Architecture

We built a standalone workspace package (packages/memory) that wraps the Cognee Cloud REST API. It exports a MemoryService interface with four methods and two implementations:
packages/memory/src/
├── MemoryService.ts # Interface: remember, recall, improve, forget, isEnabled
├── CogneeMemoryService.ts # Talks to Cognee Cloud via REST API
├── NoopMemoryService.ts # Silent fallback — all methods are no-ops
└── index.ts # Factory: reads env vars, returns the right impl

The key design decision: graceful degradation. If COGNEE_ENABLED is not true, or the API key is missing, or Cognee is unreachable, the app uses NoopMemoryService and continues working with its existing SQLite-backed state. The memory layer is an enhancement, not a dependency.

Authentication

Cognee Cloud uses two headers for multi-tenant auth:
X-Api-Key:
X-Tenant-Id:

We encapsulated these in an authHeaders() helper that injects both on every request.

Per-User Isolation

Each user gets a dedicated Cognee dataset named familexyz_user_<userId>. This gives us clean isolation — one user's memories never bleed into another's — and makes forget() simple: delete the dataset, and all the user's graph data, vectors, and relational records are gone.

Naming note: you'll see "FamilyXYZ" (the product), familexyz (the repo/package name), and famile.xyz (the live domain) used throughout this post. The codebase predates the current domain, hence the mismatch — nothing to worry about if you're cross-referencing the repo.

The Four Operations

remember() — POST /api/v1/remember

After every Telegram conversation, check-in, or family interaction, we store the content plus metadata (which agent, what source, which family member) as a text blob. Cognee's remember endpoint handles both ingestion and graph building (add + cognify combined), so we don't need a separate processing step.

const formData = new FormData();
formData.append("data", new Blob([enriched], { type: "text/plain" }), "memory.txt");
formData.append("datasetName", dataset);
// POST /api/v1/remember

recall() — POST /api/v1/recall

Before an agent responds to a user message, we call recall() to fetch relevant context from the user's memory graph. We use searchType: "CHUNKS" with topK: 5 — this returns raw text snippets directly without an LLM call, which is cheaper, faster, and gives us text we can inject into the agent's prompt as context.

body: JSON.stringify({
    query,
    datasets: [dataset],
    searchType: "CHUNKS",
    topK: 5,
})

The returned snippets are injected into the agent's system prompt as "Previous context from memory:" — giving the agent awareness of past conversations without any agent framework changes.

improve() — POST /api/v1/improve

Triggered from the web dashboard's "Improve Memory" button. Runs Cognee's enrichment pipeline (memify) on the user's knowledge graph in the background. This is fire-and-forget — if it fails, the existing graph is still usable.

forget() — POST /api/v1/forget

Triggered from the dashboard's "Forget All" button. Sends { dataset: "familexyz_user_<id>" } and Cognee handles the rest: deletes relational records, graph nodes/edges, and vector embeddings. Clean slate.

Wiring It Into the App

The memory service is a singleton, initialized once at boot:

// agent/src/index.ts
import { initMemoryService } from "@familexyz/memory";
initMemoryService();

Then in the Telegram bot's message router, before routing to an agent:

const memory = getMemoryService();
const context = await memory.recall(userId, userMessage);
// Inject context into agent prompt

And after the agent responds:

await memory.remember(userId, `User: ${userMessage}\nAgent: ${agentResponse}`, {
    source: "conversation",
    agent: "wisdom",
});

The web dashboard at famile.xyz/memory exposes the full lifecycle via REST endpoints (/api/memory/status, /api/memory/recall, /api/memory/remember, /api/memory/forget, /api/memory/improve) with JWT authentication.

What We Learned

1. The docs don't always match the API

When we first integrated, the documentation for the forget endpoint was inconsistent — the OpenAPI spec listed a forget tag, but the API reference page 404'd. We initially assumed the REST endpoint didn't exist and built a workaround (UUID lookup via GET /datasets + DELETE /datasets/{id}).

After diving into the Cognee open-source repo to contribute a PR, we discovered POST /api/v1/forget does exist and accepts { dataset: "name" } directly. We simplified our implementation to a single call.

Lesson: When the docs are unclear, read the source. Open-source projects often have better answers in the code than in the docs.

2. CHUNKS vs GRAPH_COMPLETION matters a lot

The default searchType for recall() is GRAPH_COMPLETION, which calls an LLM to generate a natural language answer from the graph. This is expensive (LLM call per recall), slow (seconds of latency), and returns an answer, not raw context.

For our use case — injecting context into an agent prompt — we want raw text snippets, not LLM-generated answers. Switching to searchType: "CHUNKS" was a significant improvement: no LLM call, sub-second latency, and text we can directly inject.

Lesson: Read the search type options carefully. The default isn't always right for your use case.

3. Graceful degradation is non-negotiable

The memory layer is optional. The app worked for months without it. If Cognee goes down, credits run out, or the network fails, the app must keep working.

Our NoopMemoryService pattern — where every method is a silent no-op — made this painless. The calling code doesn't know or care whether Cognee is active. It calls recall(), gets an empty array, and the agent responds without memory context. Not ideal, but not broken.

Lesson: When adding a cloud dependency to an existing app, wrap it in an interface with a no-op fallback. The integration becomes a feature enhancement, not a reliability risk.

4. Contributing back is the best documentation

We found issue #3748 in the Cognee repo — "Inconsistent API error responses in improve, forget, and recall routers." Three routers were returning raw error dicts with non-standard HTTP status codes (420, 409) instead of the canonical ErrorResponse DTO used by the other five routers.

We fixed it in PR #3863, and the process of reading the router source code taught us more about the API than the docs ever did. We saw exactly how each endpoint handled errors, what status codes to expect, and what the response schema looked like.

Lesson: The fastest way to understand an open-source API is to fix a bug in it.

The Stack

Layer	Technology	Why
Agent framework	ElizaOS (TypeScript)	Existing multi-agent orchestration, already in place before this integration
Memory layer	Cognee Cloud (REST API)	Managed knowledge graph — no infra to run
Backend	Hono on Node.js, PM2 on Hetzner	Lightweight, fast cold starts, cheap to run on a VPS
Frontend	Next.js on Netlify	Simple static + serverless deploy for the dashboard
Bot	Telegram Bot API	Primary interaction surface for families
Auth	JWT (HMAC-SHA256)	Stateless auth across bot and dashboard
Package manager	pnpm workspaces	Monorepo with shared packages like `@familexyz/memory`

Results

The memory layer is live in production at api.famile.xyz. A round-trip test confirms it works:

remember: Store "User checked in: mood=good, had breakfast with family" → {"success":true}
recall: Query "What did the user do this morning?" → Returns the exact memory with metadata
status: {"enabled":true,"service":"cognee"}

The Telegram bot now remembers past conversations, the web dashboard shows memory status and lets families manage their data, and the whole system degrades gracefully if Cognee is ever unavailable.

What's Next

Session-scoped memory: Cognee supports session_id for per-conversation context tracking. We could give each Telegram conversation its own session.
Node sets: Cognee's remember accepts node_set tags for grouping related data. We could tag memories by agent (wisdom, intimacy, etc.) for more targeted recall.
Scope-aware recall: Cognee's scope parameter can search "graph", "session", "trace", or "all" — we're currently using the default "auto" but could be more intentional about which memory sources to query.

FamilyXYZ is an open-source family wellness platform. The Cognee integration code is at github.com/thisyearnofear/familexyz. The Cognee PR is at github.com/topoteretes/cognee/pull/3863.

I turned café wifi speeds into a metro map — on Aurora Serverless v2 + Vercel

Papa — Mon, 29 Jun 2026 23:51:41 +0000

I Built Lattency: A Crowdsourced Metro Map for Café Wi-Fi Using Aurora PostgreSQL Serverless v2 and Vercel

Built for the H0: Hack the Zero Stack hackathon (Vercel × AWS Databases).

Stack: Amazon Aurora PostgreSQL Serverless v2 + PostGIS + Next.js on Vercel

Live Demo: https://lattency.vercel.app/

Source: https://github.com/thisyearnofear/lattency

#H0Hackathon

Finding a café with reliable Wi-Fi (in Nairobi) is surprisingly difficult.

You buy a coffee, settle in, open your laptop, and discover the network can't survive a video call. Twenty minutes later you're packing up and looking for another café.

It's a problem that quietly steals hours every week.

So I built Lattency.

Instead of reviews saying "the Wi-Fi is good", Lattency is a crowdsourced metro map where every café is a station and every line represents a Wi-Fi speed tier—not geography.

🚄 Express — 50 Mbps and above
🚉 Local — 10–49 Mbps
🚧 Suspended — Below 10 Mbps

Anyone can run a speed test, submit a measurement, and within seconds the café is reclassified for everyone else.

The interesting part wasn't drawing the map.

It was building a backend that could answer "What's the fastest café near me?", update itself in near real time, resist bad data, and cost almost nothing when nobody was using it.

This post is about the infrastructure that makes that possible.

Choosing the database

The hackathon offered three AWS database options:

Amazon DynamoDB
Amazon Aurora DSQL
Amazon Aurora PostgreSQL

For Lattency, the decision came down to one requirement:

Find cafés within a radius of the user's location.

With PostGIS, that's almost trivial.

SELECT id, name, lat, lng
FROM cafes
WHERE ST_DWithin(
    geog,
    ST_MakePoint($1, $2)::geography,
    $3
);

ST_DWithin() is exactly the kind of query PostGIS was built for.

DynamoDB has no native geospatial radius queries, and Aurora DSQL doesn't currently support PostGIS.

Once location search became a requirement, Aurora PostgreSQL wasn't simply the easiest choice—it was the only database that naturally fit the problem.

The second reason was economics.

Aurora PostgreSQL Serverless v2 scales all the way down to 0 ACUs when idle.

A project like Lattency doesn't receive traffic around the clock. It wakes up during working hours, slows down overnight, and may eventually expand city by city.

Paying only when the database is actually serving requests is exactly the pricing model I wanted.

The trade-off is a cold start of roughly 15–30 seconds after long periods of inactivity.

Fortunately, there are ways to hide that from users.

Let PostgreSQL decide the line colour

Raw speed tests are noisy.

One person on hotel Wi-Fi, a VPN, or a congested network shouldn't immediately downgrade an entire café.

Instead of calculating speed tiers on every request, Lattency maintains a materialized view that stores per-café statistics.

Every new measurement refreshes that view.

REFRESH MATERIALIZED VIEW CONCURRENTLY cafe_speed_stats;

The important part is CONCURRENTLY.

Without it, PostgreSQL would lock the view while rebuilding it.

With it, visitors continue reading from the old version while PostgreSQL prepares the new one in the background.

No downtime.

As more measurements came in, I made the aggregation smarter.

Once a café has enough submissions, measurements marked as outliers are ignored when calculating the median.

That means:

one accidental upload won't move a café into Suspended
genuine network upgrades still appear naturally over time

Outliers are excluded from the calculation—not deleted—so the underlying data remains intact.

Making serverless behave like a long-running app

Connecting a serverless application to PostgreSQL introduces three practical problems.

1. Too many database connections

Every serverless function can create its own PostgreSQL connection.

That doesn't scale very well.

Instead, I cache a single pg.Pool on globalThis, allowing warm instances to reuse existing connections.

const globalForPg = globalThis as { pool?: Pool };

export const pool =
    globalForPg.pool ??
    new Pool({
        connectionString: process.env.DATABASE_URL,
        ssl: { rejectUnauthorized: true },
        max: 1,
    });

globalForPg.pool = pool;

Keeping each instance to a single pooled connection dramatically reduces connection pressure.

2. Don't wake the database for every visitor

Most people viewing the homepage are looking at the same information.

There's no reason every request should hit Aurora.

The homepage is statically rendered using Incremental Static Regeneration.

export const revalidate = 60;

Most visitors receive a cached page from Vercel's edge network.

Aurora only needs to wake once every minute instead of once per visitor, reducing both cost and cold starts.

3. Never fail because the database is sleeping

Cold starts happen.

Instead of showing an error page while Aurora wakes up, Lattency falls back to a bundled snapshot included with the application.

The map still loads.

Users can still explore cafés.

For a hackathon demo, that's the difference between an impressive first impression and a blank screen.

4. Refresh after the response

Refreshing the materialized view isn't part of the user's request.

Using Next.js' after() API, the response is sent immediately while the refresh runs afterwards.

after(async () => {
    await refreshSpeedStats();
});

Users don't wait for maintenance work.

Crowdsourced data only works if people can't game it

Allowing anyone to contribute data is both the best feature and the biggest security problem.

I wanted automatic submissions to be more trustworthy than manually typed numbers.

Instead of asking contributors to copy results from another speed test, Lattency performs the test directly in the browser against a Vercel Edge region.

It measures:

download speed
upload speed
latency
jitter
packet loss

More importantly, the server—not the client—decides whether the submission counts as an automatic test.

const testMethod =
    body.downloadBytes &&
    body.downloadDurationMs
        ? "auto"
        : "manual";

A user can't simply claim they performed an automatic test.

The evidence has to exist.

To prevent spam without storing personal information, every IP address is salted and hashed before comparison.

createHash("sha256")
    .update(ip + process.env.RATE_LIMIT_SALT)
    .digest("hex");

The raw IP is never stored.

Rate limiting becomes:

One measurement per IP, per café, every ten minutes.

Privacy is preserved while abuse becomes significantly harder.

Adding a brand-new café is also transactional.

Creating the café and inserting its first measurement happen inside the same database transaction.

If either operation fails, everything rolls back.

The map never ends up with empty cafés that have no measurements attached.

The production architecture I almost shipped

One rabbit hole consumed far more time than I expected.

RDS Proxy.

Initially, I wanted every database connection to pass through an RDS Proxy instead of exposing Aurora directly.

I configured:

a dedicated security group
Secrets Manager credentials
IAM permissions
the proxy itself

Everything looked correct.

Nothing connected.

Eventually I realised why.

RDS Proxy is intentionally private.

Its endpoint lives inside the VPC.

That's perfect for Lambda, ECS, and EC2.

It's not designed for platforms like Vercel running outside your AWS network.

Connecting to it requires additional networking such as PrivateLink or a load balancer.

That lesson ended up being more valuable than the configuration itself.

If I were taking Lattency to production today, I'd choose one of these architectures:

Vercel × AWS Marketplace Aurora Integration — Aurora provisioned through Vercel using PrivateLink. No public database endpoint.
PrivateLink — More infrastructure, but the same private networking model.
Network Load Balancer + RDS Proxy — Works without reprovisioning, although it adds cost and operational complexity.

For the hackathon, opening PostgreSQL on port 5432 was the pragmatic decision.

I think it's more useful to explain that trade-off honestly than pretend the demo shipped with perfect infrastructure.

What I ended up with

The metro-map interface is what people notice first.

The infrastructure is what makes it believable.

Lattency combines:

Aurora PostgreSQL Serverless v2 + PostGIS for fast geospatial searches and scale-to-zero pricing.
Materialized views for outlier-aware café classification without blocking reads.
Incremental Static Regeneration so most visitors never touch the database.
Connection reuse to keep PostgreSQL healthy in a serverless environment.
Server-side trust verification so automatic measurements can't be trivially faked.
Graceful fallbacks so the application continues working even while Aurora is waking up.

The same architecture could power Wi-Fi maps for any city.

Nairobi just happened to be the first one.

If you'd like to explore it yourself:

🗺️ Live Demo: https://lattency.vercel.app/

💻 GitHub: https://github.com/thisyearnofear/lattency

I'd love to hear what you'd build with the same stack—or how you'd improve Lattency.

Built for the H0: Hack the Zero Stack hackathon.

#H0Hackathon

Cognivern - Spend OS For Agent Teams

Papa — Mon, 08 Jun 2026 06:47:42 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Cognivern is a control plane for agent operations — a SpendOS for agent teams.

As AI agents proliferate across development workflows, a quiet crisis is brewing: no one really controls what agents spend, on what, on behalf of whom, or why. Every agent gets what amounts to a blank check — against model APIs, against wallets, against third-party services. Cognivern exists to fix that.

The platform unifies governed wallet spend and AI spend governance across IDE, CLI, and agent workflows into a single auditable control layer. The core promise is simple: move fast without blank checks. Every spend decision can be policy-checked, privacy-preserving, efficiency-aware, and audit-ready — before it executes.

This matters especially in emerging markets and for teams building on-chain infrastructure, where cost overruns from runaway agents aren't just annoying — they're existential. You don't burn budget you don't have chasing a misconfigured prompt loop.

At its core, Cognivern provides:

Policy evaluation — enforce who/what/when rules before any spend executes
Privacy-native operations — evaluate sensitive policy context via confidential paths using Fhenix FHE (Fully Homomorphic Encryption)
AI spend governance — model/runtime usage visibility and optimization alongside financial controls
Audit trails — persist decision evidence (decisionId, attestation, run context) for continuous accountability
Multi-provider AI routing — ChainGPT as the primary Web3-native LLM, with Fireworks, OpenAI, Gemini, Anthropic, and others as fallbacks The stack is TypeScript + Solidity, deployed across X Layer Testnet (execution and policy), Filecoin Calibration (audit storage), and Fhenix (confidential policy state). The frontend lives at cognivern.vercel.app and includes a PromptOS terminal for natural-language governance interaction.

Demo

🔗 Live app: cognivern.vercel.app

🔗 API: cognivern.thisyearnofear.com

🔗 PromptOS Terminal: cognivern.vercel.app/os

🔗 Source: github.com/thisyearnofear/cognivern

Key flows you can explore:

Submit a spend request through the dashboard and watch policy evaluation fire in real time
Use the PromptOS terminal to interact with governance rules in natural language
Inspect the audit log — every decision has a decisionId and attestation

- Try the encrypted spend path (Fhenix), where policy is evaluated over encrypted inputs — the server never sees the raw values

The Comeback Story

Cognivern started as a hackathon project with a clear thesis but rough edges everywhere. The core governance loop worked, but it was held together with duct tape: no proper workspace isolation, no rate limiting, brittle contract interactions, and a frontend that was functional but not something you'd confidently hand to an operator.

Here's what changed during the finish-up:

Infrastructure hardening — Added per-workspace and per-API-key rate limiters with sliding windows, deep health checks, and circuit-breaker patterns. Moved to TypeScript strict mode throughout. Built out a unified CI pipeline.

172 tests — Unit, integration, and E2E via Playwright. The project went from "it works on my machine" to something with real coverage guarantees.

Multi-workspace and policy versioning — Each workspace now has independent API keys, rate limits, and a full policy version history. This was the feature that turned a demo into something a real team could adopt.

Fhenix Wave 5–7 — The FHE integration went from a proof-of-concept to a full institutional demo: encrypted policies, MEV-protected execution, selective auditor disclosure, two-phase FHE resolution with resolveDecision, sealed-bid vendor selection, and a Privara confidential payroll flow. Also migrated from Helium testnet to Arbitrum Sepolia.

ChainGPT integration — Brought in ChainGPT as the primary AI provider for Web3-native governance queries, with the Smart Contract Auditor running as runtime pre-spend defense. This felt like the missing piece — governance AI that actually understands on-chain context.

Operator UX — PromptOS terminal integrated into the sidebar, voice input via ElevenLabs STT, self-service onboarding flow, animated workspace mode toggles, full mobile responsiveness.

The project went from ~60% production-ready to ~93%. The remaining 7% is mostly production key management and a few contract audit items before mainnet.

My Experience with GitHub Copilot

Cognivern is a project with a lot of moving parts — Solidity contracts, TypeScript APIs, multi-chain deployment scripts, FHE integration, and a React frontend — often all in motion at the same time. Copilot was the connective tissue that kept things moving without constant context-switching tax.

A few specific ways it earned its keep:

Boilerplate elimination for the governance endpoints. The API has 12+ endpoints with consistent patterns — request validation, policy lookup, decision logging, response shaping. Writing the first one from scratch was fine; Copilot handled the rest, often getting the full shape right on the first suggestion.

Solidity contract work. The ConfidentialSpendPolicy contract for Fhenix was genuinely novel — FHE operations aren't something most developers have pattern-matched on. Copilot's suggestions weren't always right, but they were useful scaffolding that surfaced the right questions. The back-and-forth of accepting, rejecting, and editing suggestions was faster than writing from scratch.

Test generation. Getting to 172 tests would have taken much longer without Copilot helping generate test cases from the function signatures and existing test patterns. It's particularly good at the "write 10 edge case tests for this validator" kind of ask.

README and documentation. The architecture docs, developer guide, and deployment docs are detailed. Copilot helped maintain consistent voice and structure across them, and was surprisingly good at inferring the right level of technical detail for each audience.

The honest take: Copilot didn't make hard architectural decisions easier. The FHE integration design, the multi-chain deployment strategy, the policy versioning data model — those required real thinking. But it absorbed a huge amount of the mechanical work and kept me in flow during the push to get this finished.

Find me on Farcaster and Lens — always building at the intersection of AI, emerging markets, and on-chain infrastructure.

DiversiFi — Finishing What Inflation Started

Papa — Mon, 08 Jun 2026 06:34:44 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

DiversiFi is an AI-powered stablecoin diversification app built on Celo and Arbitrum. The premise is simple but personal: your stablecoins shouldn't all be pegged to the dollar.

If you live in Kenya — as I do — inflation isn't an abstract macroeconomic concept. It's the gap between what you earned last year and what that money buys today. It's the reason holding savings in a local currency account quietly destroys purchasing power, and why stablecoins feel like a genuine unlock: your savings can actually compound instead of erode.

But even dollar-pegged stables have their own exposure. And if you care about your continent — about African economies developing their own financial infrastructure, about emerging markets building on-chain alternatives to broken legacy rails — then a portfolio that's 100% cUSD is both financially incomplete and ideologically inconsistent.

DiversiFi tries to fix both problems at once. Connect a wallet, pick a financial philosophy, deposit stablecoins into a non-custodial Safe smart account, and let an AI agent rebalance your holdings across regional stablecoins — cUSD (US), cEUR (EU), KESm (Kenya), COPm (Colombia), PHPm (Philippines), cREAL (Brazil) — based on live inflation and economic data.

The agent doesn't just chase yield. It reads governance forums, World Bank inflation feeds, and economic signals to make allocation decisions that reflect both the numbers and the philosophy you've chosen:

Africapitalism — keep wealth circulating in African economies
Islamic Finance — Sharia-compliant, no interest-bearing assets
Buen Vivir — LatAm philosophy balancing material wealth with community wellbeing
Global Diversification — maximum geographic spread
Custom — define your own allocation targets This isn't cosmetic. Each philosophy filters which assets the agent can touch, how it weights rebalancing recommendations, and what it rules out entirely. The goal is a tool that reflects how real people in real places actually think about money — not just a generic robo-advisor with a world-map splash screen.

Built by @papajams · Lens

Demo

🔗 Live app: diversifiapp.vercel.app
📦 Repo: github.com/thisyearnofear/diversify

The Comeback Story

DiversiFi started as a hackathon prototype — the kind that works well enough for a 3-minute pitch but quietly falls apart the moment you try to actually use it.

The core flows were broken. The agent could recommend rebalances but couldn't reliably execute them. The permission system — the piece that makes this non-custodial and therefore trustworthy — was wired up but unenforced, which defeated the whole point. The UI showed allocation targets but gave no real-time feedback on what the agent was actually doing. And the financial strategy layer was mostly decorative; it influenced the copy, not the code.

The push to actually finish it came from submitting to the Ethereum México x Bitso Hackathon — a 5-week global build sprint at the intersection of AI, stablecoins, and payments, with Bitso as a key integration partner and 20% of judging weighted on LATAM real-world impact. Having real mentors and a live demo day in front of regulators and fund managers has a way of clarifying what "done" actually means.

Here's what changed:

Execution layer fixed. _executor.ts now correctly bridges the vault service to the chain via Privy smart accounts, with a local dev fallback that doesn't require a full smart account setup to test against.

Permission model enforced. Session signer policies now actually gate what the agent can spend, on which contracts, within what time bounds. The agent cannot exceed user-defined limits. This is the difference between "non-custodial" as a marketing claim and non-custodial as an architectural guarantee.

Strategy wired into agent behaviour. Each financial philosophy now filters and weights rebalance recommendations at the vault.service.ts level. Africapitalism doesn't just change the UI label — it changes which assets the agent will and won't touch.

Real transaction receipts. Transactions now log through OpenClaw with human-readable summaries. Users can see exactly what the agent did, why, and when — not just a tx hash.

Bitso integration. Added Bitso as a payment rail, bridging fiat on-ramps to on-chain stablecoin positions. For LATAM users this matters enormously: getting funds into the protocol shouldn't require already being crypto-native.

Expanded to Arbitrum. Extended beyond Celo to support Arbitrum, broadening the asset universe and giving users access to deeper liquidity pools.

Fee model stabilised. 1% annual management + 10% performance above high-water mark + 0.10% swap spread, now calculated and settled correctly at withdrawal rather than estimated and forgotten.

The project went from a prototype that made a good pitch to something I'd actually trust with a real deposit.

My Experience with GitHub Copilot

I used Copilot Chat throughout the finishing process — primarily for architecture and debugging, less as a code generator and more as a thinking partner when things got tangled.

The most valuable moments were in the permission and execution layers, which are genuinely non-trivial. ERC-4337 smart accounts, session signer policies, Privy's secure enclave model — these interact in ways that aren't obvious, and when something breaks the error messages are often unhelpfully cryptic. Being able to paste a stack trace or policy config into Copilot Chat and get a focused hypothesis about what was failing saved real time that would otherwise have gone into reading SDK internals line by line.

I also used it to pressure-test the security model. Walking through the architecture — user controls Safe, agent signs within policy, no private key on server — and asking Copilot to look for holes surfaced a few edge cases around policy expiry and fallback signing I hadn't thought through carefully enough. Having something push back on your assumptions is underrated.

It's not magic. It didn't know Mento Protocol's quirks or Celo's specific bundler constraints out of the box. But as a tool for reasoning through complex, interlocking systems — rather than just autocompleting boilerplate — Copilot Chat earned its place in this build.

Find me on Farcaster and Lens — always building at the intersection of AI, emerging markets, and on-chain infrastructure.

WebMCP Might Be the Most Important Announcement at Google I/O 2026

Papa — Mon, 25 May 2026 00:49:35 +0000

Every few years a technology shows up that looks like a product but is actually a protocol. When that happens, the product gets forgotten and the protocol becomes infrastructure. Google I/O 2026 had one of those moments. It just didn't get treated like one.

The models were impressive. Gemini 3.5 Flash is four times faster than its predecessors. Antigravity 2.0 makes agent orchestration feel like something you'd actually ship. AI Studio now deploys to Cloud Run in one click. None of it was architecturally surprising. But buried in the developer sessions was something different: WebMCP, a proposed open standard for exposing structured tools to browser-based AI agents.

That one is worth sitting with.

The Failure Mode Everyone Already Knows

If you have ever maintained Selenium automation for more than six months, you already understand the problem WebMCP is trying to solve.

The automation works until the product team redesigns the checkout page. Then the selector breaks. You fix it. Three weeks later the login flow changes. You fix it again. You are not engineering anything — you are running a permanent rearguard action against a UI that was never designed to stay still. The automation is fragile because it is built on inference: your code is guessing at intent by reading presentation.

The first generation of browser AI agents have exactly this problem, at larger scale and higher stakes. They can see buttons and forms and navigation menus, and they can click on things, but they are always one redesign away from failing. They are imitating human behavior because the web has never offered them an alternative.

Imagine booking a flight through an agent today. The agent visually searches for departure fields, date pickers, seat selectors, and payment buttons. Every redesign risks breaking the workflow. Under WebMCP, the airline could expose booking itself as a structured capability: destination, dates, passenger count, seat preferences, payment authorization. The agent stops navigating the interface and starts interacting with the system underneath it.

WebMCP is the alternative.

The standard lets web developers expose structured tools — JavaScript functions, typed parameters, form interactions — as machine-readable capabilities. Instead of an agent inferring "this is probably a search box" by parsing the DOM, the site simply declares: here is a search function, here are its inputs, here is what it returns. Declarative for standard interactions, imperative for anything requiring runtime JavaScript. Chrome's experimental origin trial starts in Chrome 149.

The immediate gain is reliability. But that is not the interesting part.

What Changes Under the Surface

Websites have always been designed around visibility. If a human could see and operate something, the web had succeeded. That assumption ran so deep it was invisible — interfaces were presentation layers, and making them look right was the whole job.

WebMCP introduces a different assumption: systems may not need to be visually navigable to be operationally useful. The interface stops being primarily a presentation layer and starts being a capability surface.

That is a significant mutation.

An airline site exposing a structured booking capability is no longer just a place you visit. It becomes a service an agent can call directly. The distinction between website and API starts to blur at the protocol level, not just for developers, but for the web itself.

There is historical precedent for this shift.

RSS made web content machine-readable. A feed reader did not have to scrape a blog and guess where the article title ended and the sidebar began. The site simply exposed structure directly. RSS eventually collapsed as a consumer technology, but the idea it proved — that structured syndication beats scraping — became foundational to modern content APIs.

WebMCP does for actions what RSS did for content.

That distinction matters enormously.

Content syndication is passive. The machine reads what a human wrote. Action exposure is active — the machine performs operations on a user's behalf, with real-world consequences. The jump from "readable" to "actionable" changes the ontology of the web itself.

This is what Google is quietly building toward.

Antigravity 2.0 orchestrates agents. Gemini Spark acts across Gmail, Calendar, and eventually third-party tools via MCP. But agent workflows are only as reliable as the surfaces they operate on. The whole agentic stack presupposes that websites will eventually expose structured interfaces for machine consumption.

WebMCP is the specification for what that looks like on the open web.

The Critique You Have to Make

Here is where most conference coverage goes soft.

WebMCP only matters if adoption follows. An open standard with one browser behind it and no ecosystem buy-in is just a Chrome experiment. The history of proposed web standards is mostly a graveyard of promising ideas that died waiting for critical mass, or got implemented inconsistently enough that developers ended up writing workarounds anyway — which is to say, they ended up back at the Selenium problem.

Google has enough platform leverage to push Chrome 149 to most of the world's browsers in six months. It does not have the same leverage over every site that agents will need to use. The gap between "here is a standard" and "here is a standard that Stripe and Shopify and healthcare portals have implemented correctly" is years of developer effort and business negotiation. Nothing about announcing a standard compresses that timeline.

There is also a safety question the I/O coverage largely sidesteps.

Structured tool exposure is a double-sided surface. Right now browser agents are limited partly for the same reason they are safe: they cannot do that much. A web where every site exposes clean, machine-actionable capabilities is a web where the blast radius of a compromised or misbehaving agent gets significantly larger.

The permissions model, the consent model, the audit trail — none of that is solved by declaring "here are the actions this site supports." If anything, it sharpens the accountability question.

The infrastructure is arriving faster than the trust guarantees.

That is the honest summary of where agentic development actually sits right now. Not just for WebMCP — for all of it.

Why This Is Still the Story

None of those concerns make WebMCP less important. They make it more important to track carefully.

The DEV community's instinct after I/O was telling. The submissions that resonated were not about model benchmarks. They were about infrastructure, about privacy, about frameworks designed for machines as much as humans. That pattern is not accidental.

Developers who ship things for a living have a reliable nose for where the actual work is going to land, and right now that nose is pointing at integration — not intelligence.

The capability problem is closer to solved than most people want to admit. Models reason well. Models act. What remains unsolved is making those actions reliable, auditable, and safe at scale.

That is an infrastructure problem.

And infrastructure problems get solved by protocols, not products.

WebMCP is an early answer to the question of what reliable agent-web interaction should look like. It will probably not be the final answer. RSS wasn't either. But RSS proved the idea was viable, and everything that followed built on that proof.

The original web connected documents.

The next version may connect capabilities — not just for humans navigating pages, but for agents executing intent.

The web was built for humans to navigate.

The next version may be built for agents to operate.

Submitted for the Google I/O 2026 Writing Challenge on DEV.