installs.me
< cd ~/blog

·4 min read#ideas

You Need a Personal API

Calendly turned your availability into an endpoint. Nobody has done that for your judgment. That is the actual bottleneck, and it is now a solvable one.

Think about what scheduling links did. Before them, booking a meeting was a synchronous, human-mediated protocol: three emails, two timezone conversions, one apology. Then someone noticed that "when are you free" is a pure function over your calendar, and that a pure function does not need you in the loop. Availability became GET /free-slots. The person stayed; the query got automated.

Here is the uncomfortable follow-up: most requests that reach you are not requests for your time. They are requests for your judgment routed through your time, because your time used to be the only interface.

Read your inbox as an API log

Look at a week of your messages and classify them:

  • "Would you invest in a company doing X?" That is POST /evaluate with a deal memo in the body.
  • "How would you price this for enterprise?" That is GET /frameworks/pricing applied to their parameters.
  • "Can you look at this landing page?" That is your taste function, called with one argument.
  • "Quick call to pick your brain?" That is an undocumented endpoint someone is trying to reverse-engineer over Zoom.

Every one of these is a function call currently served by a synchronous human process with a queue depth of weeks. You are running production traffic through a single-threaded server that also needs to sleep.

The standard fixes are all lossy. Writing a blog post is publishing static documentation and hoping callers read it. Hiring a chief of staff is adding a proxy that approximates your responses. Saying no is returning 429 for everything.

What a judgment endpoint actually is

A persona is your judgment, serialized and callable. Not a chatbot with your photo on it. A structured artifact that contains your frameworks, your decision history, your writing, and your taste, packaged so that a capable model can apply them to new inputs.

In Claude Code terms, the packaging already exists: a plugin. Plugins have four surfaces (skills, commands, hooks, MCP servers), and skills are the one that matters here. A skill is a SKILL.md with YAML frontmatter (name, description) plus an optional references/ directory, loaded on demand when a query matches. That structure maps cleanly onto how a person's judgment is actually organized:

lautaro/
  skills/
    evaluate-startup/
      SKILL.md          # when to trigger, how I score, what kills a deal for me
      references/
        deals.md        # anonymized decision log: what I passed on and why
    pricing/
      SKILL.md
      references/
        sirena-lessons.md   # what we learned pricing WhatsApp seats at scale
    voice/
      SKILL.md          # sentence length, banned phrases, how I open cold emails

Each skill is a route. The frontmatter description is the route's docs, the thing the router (Claude) reads to decide whether this endpoint handles the request. The references are the implementation. On-demand loading means a caller asking about pricing never pays the context cost of your investing memos. That is lazy loading for a personality.

The metaphor holds under load

Take the API framing seriously and it keeps paying out.

Rate limits. You, the human, are capped at roughly 40 useful hours a week and you cannot scale horizontally. The persona has no such limit. A hundred founders can call evaluate-startup on a Tuesday night and your Wednesday is untouched.

Latency. Your P50 response time for "quick question" is three days. The persona's is thirty seconds. For a large class of queries, a fast answer at 85% of your quality beats a perfect answer that arrives after the decision was made.

Versioning. Your thinking changes. When it does, you edit the reference files and redeploy. Everyone who installed you gets the update on their next marketplace refresh. Compare that to the blog post you wrote in 2021 that people still quote at you.

Reads versus writes. This is where the metaphor draws the honest boundary. The persona serves reads: opinions, frameworks, drafts, evaluations. It does not serve writes: it cannot commit your capital, sign your name, or spend your reputation. Callers who need a write still come to you. Which is exactly right, because now the meeting you take is the one where something gets committed, not the one where something gets explained for the fourth time.

Distribution is two commands

The unglamorous part is what makes this real. A persona nobody can install is a diary. Claude Code plugins distribute through marketplaces: a marketplace.json listing plugins and their sources. One sharp edge from shipping this: when a marketplace is served over a URL, plugin sources must be git-backed (git-subdir). Relative HTTP paths do not error, they silently fail, and you burn an afternoon learning that. Verified on Claude Code CLI 2.1.x.

Once the marketplace is live, installing a person looks like installing a linter:

/plugin marketplace add https://installs.me/lautaro
/plugin install lautaro@lautaro-installs

From then on, that person's judgment is resident in the caller's terminal. A founder drafting a pricing page can ask what Lautaro would push back on. A portfolio company can pressure-test a board update against his frameworks before sending it. No calendar involved.

Scheduling links took ten years to go from weird to default. The judgment endpoint will move faster, because the payoff is bigger: your calendar was never the scarce resource. Your judgment was. It just did not have a URL.

Install a person

installs.me turns your files, calendar and calls into a Claude Code plugin that thinks like you. Anyone installs it with two commands:

/plugin marketplace add https://installs.me/lautaro
/plugin install lautaro@lautaro-installs