Forem: Ben Stone

The Commerce Layer Problem in Multi-Agent Systems

Ben Stone — Mon, 13 Apr 2026 13:25:59 +0000

The easiest way to misunderstand the agent economy is to treat it like a model race.

Most teams still talk about multi-agent systems as if the core question is orchestration quality. Which framework should route the task? Which model should take the first pass? Which retry policy squeezes out a few more points of reliability? Those questions matter. They are not the wall the market is about to hit.

The wall is commercial.

As soon as one agent has to discover another agent, agree on scope, lock payment, verify delivery, and decide whether that counterparty should be trusted next time, the problem stops looking like workflow automation and starts looking like infrastructure for a market. That is the shift most teams are late to.

SwarmSync is interesting because the repo points at that missing layer directly. The AP2 flow is not described as chat completion with extra steps. It is described as a transaction sequence: discover, negotiate, escrow held, deliver, escrow released. That order matters. It turns agent work into a legible state machine with economic consequences.

The counterintuitive claim here is simple: the next bottleneck in multi-agent systems is not better reasoning. It is better settlement.

That sounds backwards until you look at where real failures happen. Systems do not break only because the output was weak. They break because the wrong provider was selected, because the work terms were vague, because nobody could prove completion, or because there was no mechanism for transferring trust from one successful transaction to the next. Intelligence alone does not solve those problems. Protocol design does.

This is why SwarmSync’s surrounding components matter. Conduit is positioned as a tamper-evident proof layer for browser execution. SwarmScore converts execution and commercial reliability into portable reputation over a 90-day window. The discovery layer ranks more than capability; it also accounts for trust, price, freshness, and relevance. Put those together and you stop asking, “Can an agent do work?” and start asking the more useful question: “Can an agent participate in a trustworthy market?”

For enterprise developers and CTOs evaluating agent infrastructure, that difference is not academic. A workflow engine can coordinate a demo. A commerce layer can coordinate recurring economic behavior between autonomous parties. One helps you show the future. The other helps you survive it.

The market will reward the teams that make agent transactions legible, verifiable, and repeatable. That is a harder problem than writing one more orchestration wrapper. It is also the one with a moat.

So the next time someone frames the category as model quality plus tooling glue, push back. The real question is whether agents can discover, negotiate, verify, and settle with enough trust to do it again tomorrow. If they cannot, the system is still a prototype wearing production clothes.

SwarmSync — The Agent-to-Agent Marketplace | IETF Open Standards

The first marketplace for agent-to-agent commerce. The AP2 Protocol handles discovery, escrow, and settlement. No payment infrastructure to build.

swarmsync.ai

Your site looks fine to Google. It might be invisible to AI.

Ben Stone — Fri, 27 Mar 2026 22:00:42 +0000

Your site looks fine to Google. It might be invisible to AI.

Traditional SEO is no longer the whole game.

A growing share of discovery now happens inside tools like ChatGPT, Claude, Perplexity, Grok, and Google AI Overviews. But most websites are still built mainly for humans and traditional search engines. That creates a new problem: a site can look polished, rank decently, and still be much harder for AI systems to crawl, interpret, and cite than most teams realize.

That gap is exactly why we built [ConduitScore]

ConduitScore scans a public website and evaluates the technical and content signals that affect whether AI systems can access, understand, and surface it. Today, it checks 14 signals across 7 categories: crawler access, structured data, llms.txt, content structure, technical health, citation signals, and content quality. It then shows what is helping, what is hurting, and what to fix first. :contentReference[oaicite:1]{index=1}

AI visibility is not the same as SEO

Most SEO tools are built to answer questions like:

Are we ranking?
Are our pages indexed?
Are we targeting the right keywords?

Those still matter.

But AI systems evaluate websites differently. They are also asking:

Can I access this content cleanly?
Can I tell what this company actually is?
Is the page structure easy to parse?
Are there enough trust and entity signals to cite this confidently?
Is the content clear enough to extract into an answer?

That is a different layer of readiness.

And many sites are weaker there than they think.

Most sites are not broken. They are leaking AI visibility.

What we kept seeing was not one catastrophic issue.

It was a pattern of smaller problems that add up:

blocked or unclear crawler access
weak or missing schema
no llms.txt
poor content structure
weak citation and trust signals
thin page-level explanations
missing canonical or indexing hygiene
vague company/entity signals

Individually, each one can look minor.

Together, they make it much harder for AI systems to understand what your site is, what it offers, and whether it is safe to use as a source.

That is why a site can look fine to a human, look fine in a basic SEO crawl, and still underperform in AI-generated answers.

What ConduitScore actually checks

We wanted something more useful than vague advice like “make your site more AI-friendly.”

So ConduitScore measures concrete signals.

On the site today, those checks include things like GPTBot, ClaudeBot, PerplexityBot, and OAI-SearchBot access, sitemap fetchability, Organization and WebSite schema, llms.txt, canonical tags, noindex issues, HTTPS, contact/entity/trust signals, semantic HTML structure, title quality, and meta description quality. :contentReference[oaicite:2]{index=2}

The point is not just to generate a score.

The point is to answer a much more practical question:

What is blocking AI visibility right now, and what should we fix first?

That is why ConduitScore does not just spit out a number. It also shows the top issues holding the site back and prioritizes the highest-impact fixes first. The sample reports on the site follow the same pattern, including clear “what’s working,” “minor improvements,” and specific fix recommendations. :contentReference[oaicite:3]{index=3}

The shift teams need to make

The old mindset was:

How do we rank?

The new mindset is:

How do we make our site easy for AI systems to read, trust, and surface?

That does not replace SEO. It expands it.

Google rankings still matter. But if more product discovery, research, and comparison behavior is happening inside AI tools, then being easy for those systems to interpret becomes a real growth issue.

This is especially true for:

SaaS companies
agencies
SEO teams
ecommerce brands
content-heavy sites that depend on being cited or summarized accurately

That is also why ConduitScore is positioned less like a traditional SEO audit and more like an AI visibility diagnostic. The homepage is explicit about that difference: SEO tools show how you rank in search engines, while ConduitScore is focused on whether AI systems can read, interpret, and surface your site in AI-generated answers. :contentReference[oaicite:4]{index=4}

The biggest wins are usually boring

The good news is that low AI visibility usually does not mean your site is fundamentally bad.

It usually means your site is missing a handful of machine-readability and trust signals that are fixable.

In practice, some of the highest-leverage fixes are often pretty boring:

allowing the right crawlers
improving schema
adding a real llms.txt
cleaning up headings and semantic HTML
improving intro copy and summaries
making entity and trust signals more explicit
fixing canonical and indexing issues

These are not flashy changes.

But they reduce ambiguity.

And for AI systems, ambiguity is expensive.

Why we built ConduitScore

We built [ConduitScore] because this problem is becoming real before most teams have tooling for it.

More companies are asking versions of the same question:

Can AI actually see our site clearly — and if not, why not?

That is what ConduitScore is meant to answer.

Not with hype.
Not with hand-wavy AI SEO language.
With a concrete scan, a score, a breakdown of issues, and a prioritized fix list.

If you want to check your own site, run a scan at [conduitscore.com]

Building Auditable AI Agents with Conduit

Ben Stone — Wed, 11 Mar 2026 23:46:46 +0000

The Accountability Gap in AI Agent Tooling

AI agents are getting good at browsing the web. They can navigate pages, fill out forms, extract data, and complete multi-step workflows. But there's a gap that most agent frameworks ignore: accountability.

When an agent uses a browser, what evidence exists of what it actually did? Typically, you get logs -- plaintext files that anyone can edit after the fact. Maybe screenshots, which can be fabricated. There's no cryptographic guarantee that the record of an agent's browser session is authentic and unmodified.

This matters more than most people realize. If you're deploying agents in regulated industries (finance, healthcare, legal), you need auditable records. If you're running an agent marketplace, buyers need proof that agents performed the work they claim. If an agent makes a mistake, you need a tamper-evident trail to understand what happened.

What Conduit Does

Conduit is a headless browser library for Python that builds a SHA-256 hash chain around every browser action and signs the result with Ed25519. It's built on top of Playwright, so it inherits all of Playwright's automation capabilities and adds a cryptographic trust layer on top.

Here's the core idea: every time the browser does something -- navigates, clicks, fills a form, takes a screenshot -- that action gets recorded as a structured event and hashed with SHA-256. Critically, each hash includes the previous hash, forming a chain. If any action in the chain is modified, every subsequent hash breaks. This is the same principle behind blockchain, applied to browser sessions.

At the end of a session, the entire hash chain is signed with an Ed25519 private key. The output is a "proof bundle" -- a self-contained JSON file that includes the action log, the hash chain, the signature, and the public key needed to verify it.

Getting Started

Install from PyPI:

pip install conduit-browser

Basic usage:

import asyncio
from conduit import ConduitBrowser

async def main():
    async with ConduitBrowser() as browser:
        page = await browser.new_page()

        # Every action is recorded and hashed
        await page.goto("https://example.com")
        await page.click("a[href='/about']")
        await page.screenshot(path="about.png")

        # Get the proof bundle
        proof = await browser.get_proof_bundle()

        # Save it
        with open("session_proof.json", "w") as f:
            json.dump(proof, f, indent=2)

asyncio.run(main())

The proof bundle looks like this:

{
  "session_id": "c3f8a...",
  "actions": [
    {
      "type": "navigate",
      "url": "https://example.com",
      "timestamp": "2026-03-11T14:30:00Z",
      "hash": "a1b2c3..."
    },
    {
      "type": "click",
      "selector": "a[href='/about']",
      "timestamp": "2026-03-11T14:30:01Z",
      "previous_hash": "a1b2c3...",
      "hash": "d4e5f6..."
    }
  ],
  "chain_root": "d4e5f6...",
  "signature": "ed25519_sig_...",
  "public_key": "ed25519_pub_..."
}

Verifying a Proof Bundle

Verification is independent -- anyone can verify a proof bundle without trusting the party that created it:

from conduit import verify_proof_bundle
import json

with open("session_proof.json") as f:
    proof = json.load(f)

result = verify_proof_bundle(proof)

if result.valid:
    print("Chain intact, signature valid")
    print(f"Actions: {result.action_count}")
    print(f"Session duration: {result.duration}")
else:
    print(f"Verification failed: {result.reason}")

The verifier checks two things:

Hash chain integrity -- Recomputes every hash and confirms the chain is unbroken
Signature validity -- Verifies the Ed25519 signature over the chain root using the embedded public key

MCP Server for AI Agents

Conduit ships as an MCP (Model Context Protocol) server. This means LLM-based agents -- Claude, GPT, or any MCP-compatible system -- can use Conduit natively through tool calls.

{
  "mcpServers": {
    "conduit": {
      "command": "conduit-mcp",
      "args": ["--stealth"]
    }
  }
}

Once configured, the agent gets access to tools like browse, click, fill, screenshot, and get_proof_bundle. The hash chain builds itself in the background. The agent doesn't need to manage the audit trail -- it just uses the browser and the proof is automatic.

Stealth Mode

An auditable browser that gets blocked isn't useful. Conduit includes stealth mode with common fingerprint evasion techniques: realistic viewport sizes, user-agent rotation, WebDriver flag masking, and other standard anti-detection measures. It's not a silver bullet against sophisticated bot detection, but it handles the common checks.

async with ConduitBrowser(stealth=True) as browser:
    # Fingerprint evasion is active
    page = await browser.new_page()
    await page.goto("https://target-site.com")

Real-World Use Cases

Compliance automation: An agent processes GDPR data subject access requests. Each request involves logging into a portal, locating records, and exporting data. Conduit provides a proof bundle for each request that auditors can independently verify.

Web scraping provenance: A data provider scrapes pricing data for clients. Each scraping session produces a proof bundle proving exactly which pages were visited, when, and that the collected data matches what was on the page.

Agent marketplaces: A buyer hires an agent to perform research. The agent returns results plus a proof bundle. The buyer verifies the agent actually visited the claimed sources.

Litigation support: A law firm needs to capture the current state of a web page as evidence. Conduit provides a cryptographic chain of custody for the capture.

Open Source, No Strings

Conduit is MIT licensed. No API keys, no accounts, no telemetry. The cryptographic keys are generated locally. Proof bundles are self-contained -- verification requires no external service.

GitHub: https://github.com/bkauto3/Conduit
PyPI: pip install conduit-browser
Docs: https://swarmsync.ai/conduit

Conduit is part of the SwarmSync ecosystem -- a set of open-source and commercial tools for building trustworthy AI agent systems. If you're building agents that interact with the real world, auditable tooling isn't a luxury. It's infrastructure.

Star the repo, try it out, and let me know what you build with it.

I Built a Client Profitability Dashboard for Freelancers (and Launched It Today)

Ben Stone — Tue, 17 Feb 2026 02:22:17 +0000

I Built a Client Profitability Dashboard for Freelancers

The Problem That Wouldn't Leave Me Alone

61% of freelancers lose 10-30% of project revenue to scope creep and time leaks, according to PMI research. But here's the scarier stat: most freelancers can't tell you which of their clients is actually profitable.

Your highest-paying client might be your least profitable one when you account for all the hidden time: the extra revision rounds, the 45-minute calls about a 5-minute task, the scope creep that "won't take long."

QuickBooks makes this worse, not better. Per-project P&L requires Plus at $115/month or Advanced at $235/month. And the October 2025 interface redesign increased clicks required for basic tasks "by at least five times" (direct quote from G2 reviews).

What I Built: ClientPulse

ClientPulse is a single-screen dashboard that answers one question: "Which clients are making me money and which are costing me money?"

Core Features

Per-Client Profitability Dashboard

Syncs with QuickBooks or Xero via OAuth
Shows true effective hourly rate (total revenue / ALL hours including admin, meetings, revisions)
Color-coded: Green = profitable, Yellow = breakeven, Red = losing money

Real-Time Scope Creep Alerts

Alerts at 20%, 50%, 80%, 100% over estimated hours
Catches scope creep while you can still have the conversation
Not after the project ends when it's too late

The Wow Moment
Connect QuickBooks → See client profitability ranked in 30 seconds.

Tech Stack

Next.js 15 (App Router, TypeScript)
Prisma v7 + PostgreSQL (Neon)
NextAuth.js v5 (Google OAuth + Magic Link)
Stripe for subscriptions ($29/mo Solo, $49/mo Team)
Tailwind CSS with custom dark theme (Electric Indigo + profit/scope/loss colors)

Interesting Technical Decisions

Prisma v7 Breaking Change: Prisma v7 completely removed the url field from the datasource block in schema.prisma. You now configure the adapter in prisma.config.ts. This caught me off guard during the Vercel build.

Lightweight Middleware: Using NextAuth's auth() helper in Next.js middleware caused Edge Function size to exceed 1MB (Vercel free plan limit). Fixed by doing a simple cookie check instead of importing the full auth bundle.

Effective Rate Calculation: totalRevenue / totalHours where totalHours includes ALL time categories (BILLABLE, ADMIN, REVISIONS, MEETINGS, UNBILLABLE). This is the real number, not the flattering one.

What's Next

Set up real Neon database (currently using placeholder)
QuickBooks and Xero OAuth integration testing
Scope creep detection algorithm refinement
Weekly profit pulse emails via Resend

Try It

Live: https://clientpulse-beta.vercel.app

If you're a freelancer who's ever suspected one of your "best" clients was actually costing you money - this is for you.

Built using the One-Shot Pipeline methodology: market research → SEO strategy → design system → tech spec → construction → E2E testing → deployment, all in one afternoon.

Building ClipSearch: AI-Powered Product Sourcing for Interior Designers

Ben Stone — Tue, 20 Jan 2026 21:58:22 +0000

Building ClipSearch: AI-Powered Product Sourcing for Interior Designers

I just launched ClipSearch, a product sourcing tool for interior designers. This post covers the technical architecture, interesting challenges, and what I learned building a Chrome extension + web app with AI-powered search.

The Problem Space

Interior designers browse hundreds of products across dozens of websites every week. They need to:

Save products from any e-commerce site
Organize items by project/client
Find products later (often by vague descriptions)
Present curated selections to clients

Traditional solutions (bookmarks, screenshots, Pinterest) break down at scale.

Tech Stack

Frontend:

Next.js 14 (App Router)
TypeScript
Tailwind CSS
Shadcn/ui components

Backend:

Supabase (PostgreSQL + Auth)
pgvector extension for semantic search
OpenAI API (text-embedding-3-small model)

Chrome Extension:

Manifest V3
Content scripts for product scraping
Background service worker for API calls

Deployment:

Fly.io (Next.js app)
Supabase cloud (database)
Chrome Web Store (extension)

Architecture Overview

┌─────────────────┐
│ Chrome Extension│ ──┐
└─────────────────┘   │
                      ├──> Next.js API Routes
┌─────────────────┐   │         │
│   Web App       │ ──┘         │
└─────────────────┘             ▼
                         ┌──────────────┐
                         │  Supabase    │
                         │  PostgreSQL  │
                         │  + pgvector  │
                         └──────────────┘
                                │
                                ▼
                         ┌──────────────┐
                         │  OpenAI API  │
                         │  Embeddings  │
                         └──────────────┘

Key Features & Implementation

1. Chrome Extension Product Clipping

The extension uses content scripts to extract product information from any website:

// content-script.ts
function extractProductInfo(): ProductData {
  // Try Open Graph meta tags first
  const ogImage = document.querySelector('meta[property="og:image"]')?.content;
  const ogTitle = document.querySelector('meta[property="og:title"]')?.content;
  const ogPrice = document.querySelector('meta[property="og:price:amount"]')?.content;

  // Fallback: heuristic detection
  const priceElement = document.querySelector('[class*="price"], [id*="price"]');
  const titleElement = document.querySelector('h1, [class*="product-title"]');

  return {
    url: window.location.href,
    title: ogTitle || titleElement?.textContent || document.title,
    price: ogPrice || extractPriceFromText(priceElement?.textContent),
    imageUrl: ogImage || findLargestImage(),
    source: new URL(window.location.href).hostname
  };
}

Challenge: Different e-commerce sites structure their HTML differently. Solution: Multi-layered extraction (Open Graph → schema.org → heuristics).

2. AI Semantic Search

Users can search by describing items ("find mid-century credenzas under $2000") rather than exact keywords.

Implementation:

// app/api/search/route.ts
export async function POST(req: Request) {
  const { query, userId } = await req.json();

  // Generate embedding for search query
  const embedding = await openai.embeddings.create({
    model: "text-embedding-3-small",
    input: query,
  });

  // pgvector similarity search
  const { data, error } = await supabase.rpc('search_clips', {
    query_embedding: embedding.data[0].embedding,
    match_threshold: 0.7,
    match_count: 20,
    user_id: userId
  });

  return Response.json(data);
}

Database function:

CREATE FUNCTION search_clips(
  query_embedding vector(1536),
  match_threshold float,
  match_count int,
  user_id uuid
)
RETURNS TABLE (
  id uuid,
  title text,
  similarity float
)
LANGUAGE plpgsql
AS $$
BEGIN
  RETURN QUERY
  SELECT
    clips.id,
    clips.title,
    1 - (clips.embedding <=> query_embedding) as similarity
  FROM clips
  WHERE clips.user_id = user_id
    AND 1 - (clips.embedding <=> query_embedding) > match_threshold
  ORDER BY clips.embedding <=> query_embedding
  LIMIT match_count;
END;
$$;

Why pgvector?

Native PostgreSQL extension (no separate vector DB)
Scales to millions of vectors
Cosine similarity operator (<=>) is fast
Works seamlessly with existing relational data

3. Visual Image Search

Users can upload inspiration photos and find similar items they've saved.

// Using CLIP-like approach
async function visualSearch(imageFile: File, userId: string) {
  // Convert image to embedding
  const imageEmbedding = await openai.embeddings.create({
    model: "text-embedding-3-small",
    input: await imageToBase64(imageFile),
  });

  // Same pgvector search, but with image embedding
  return supabase.rpc('search_clips', {
    query_embedding: imageEmbedding.data[0].embedding,
    match_threshold: 0.6, // Lower threshold for visual similarity
    match_count: 30,
    user_id: userId
  });
}

4. Extension <-> Web App Authentication

Challenge: Share authentication state between Chrome extension and web app.

Solution: Token-based flow

// Extension: popup.tsx
async function authenticate() {
  // Open web app for OAuth
  const tab = await chrome.tabs.create({
    url: `${WEB_APP_URL}/extension-auth`
  });

  // Listen for auth token
  chrome.runtime.onMessage.addListener((message) => {
    if (message.type === 'AUTH_TOKEN') {
      // Store token in extension storage
      chrome.storage.local.set({ authToken: message.token });
    }
  });
}

// Web app: app/extension-auth/page.tsx
export default function ExtensionAuth() {
  useEffect(() => {
    const session = await supabase.auth.getSession();

    // Send token to extension
    if (window.opener) {
      chrome.runtime.sendMessage({
        type: 'AUTH_TOKEN',
        token: session.access_token
      });
      window.close();
    }
  }, []);
}

5. Price Tracking

Background job checks saved products for price changes:

// Cron job (runs daily)
async function checkPriceChanges() {
  const clips = await supabase
    .from('clips')
    .select('*')
    .not('url', 'is', null);

  for (const clip of clips) {
    const currentPrice = await scrapePrice(clip.url);

    if (currentPrice && currentPrice !== clip.price) {
      await supabase.from('price_changes').insert({
        clip_id: clip.id,
        old_price: clip.price,
        new_price: currentPrice,
        changed_at: new Date().toISOString()
      });

      // Update clip price
      await supabase
        .from('clips')
        .update({ price: currentPrice })
        .eq('id', clip.id);
    }
  }
}

Interesting Challenges

1. Embedding Generation at Scale

Problem: Generating embeddings for every clipped product is expensive (API costs).

Solution:

Cache embeddings aggressively
Batch embedding generation (up to 100 texts per API call)
Only regenerate if title/description changes significantly

async function generateEmbeddings(clips: Clip[]) {
  // Batch up to 100 clips
  const batches = chunk(clips, 100);

  for (const batch of batches) {
    const texts = batch.map(c => `${c.title} ${c.description}`);

    const response = await openai.embeddings.create({
      model: "text-embedding-3-small",
      input: texts,
    });

    // Update all clips in batch
    await supabase.from('clips').upsert(
      batch.map((clip, i) => ({
        ...clip,
        embedding: response.data[i].embedding
      }))
    );
  }
}

2. Chrome Extension Content Security Policy

Problem: Manifest V3's strict CSP blocks inline scripts and eval().

Solution:

Move all logic to service workers
Use message passing for communication
Pre-compile templates (no runtime JSX in content scripts)

3. Handling Authentication Across Contexts

Problem: Supabase session cookies don't work across extension and web app.

Solution: Token-based auth with secure storage:

Web app uses cookie-based sessions (httpOnly, secure)
Extension uses token-based auth (stored in chrome.storage.local)
Tokens are short-lived (1 hour) with refresh mechanism

Performance Optimizations

Database Indexing

-- Critical indexes for performance
CREATE INDEX idx_clips_user_id ON clips(user_id);
CREATE INDEX idx_clips_embedding ON clips USING ivfflat (embedding vector_cosine_ops);
CREATE INDEX idx_clips_created_at ON clips(created_at DESC);

Next.js Optimizations

Server Components for initial page loads
Dynamic imports for heavy components
Image optimization with next/image
Route caching with revalidate

// app/dashboard/page.tsx
export const revalidate = 60; // Cache for 60 seconds

export default async function Dashboard() {
  const clips = await getClips(); // Server-side fetch

  return (
    <Suspense fallback={<ClipsSkeleton />}>
      <ClipGrid clips={clips} />
    </Suspense>
  );
}

Lessons Learned

1. Start with Constraints

I initially wanted to support image recognition for all products on the web. Scoping down to "help designers organize what they already find" made the MVP achievable.

2. pgvector is Production-Ready

I was skeptical about using PostgreSQL for vector search instead of Pinecone/Weaviate. pgvector has been rock-solid and eliminates operational complexity.

3. Chrome Extension Distribution is Slow

The Chrome Web Store review process takes 3-7 days. Plan accordingly for updates.

4. Pricing is Hard

Choosing $24/month was based on competitive analysis, but I'm still not sure if it's optimal. B2B tools can charge more; productivity tools need volume.

What's Next

Planned features:

Bulk import from Pinterest/bookmarks
Shared folders for team collaboration
Integration with design software (Mood boards, CAD tools)
Mobile app (React Native)

Scaling considerations:

Move to dedicated vector DB if >1M clips
Add caching layer (Redis) for search results
Implement rate limiting for API routes

Try It Out

ClipSearch is live at https://designshelf.biz

Free tier includes:

150 clips/month
AI semantic search
Visual image search
Folder organization

Would love feedback from the dev community, especially on:

The extension architecture
Vector search performance
Pricing strategy

Code Snippets & Resources

Full tech stack:

Questions? Drop them in the comments or reach out! Happy to discuss any of the technical decisions in more detail.

Built with ☕ and TypeScript