A domain specific harness is that harness that is tuned to one vertical's tools, workflows, failure modes, and edge cases. The idea being if the model is a commodity the value will accrue where the actions are decided and done.

An agent harness is the translation layer between an AI model and the environment it needs to interact with.
An agent is the result of pairing the AI model with a harness.

A harness requires at least:
1. A system prompt, which explains to the AI model what it is and how it should act.
2. Describe a set of tools and capabilities, usually known as skills and MCPs.
3. Translation layer to allow it work with different models and their intrinsicallities.
4. Agent loops: an AI agent receives a task, uses tools to gather information, checks whether the results are good enough, and repeats steps if needed. Once satisfied, it creates the final output and delivers it to the user.

Fine-tune those four for a specific domain and verticalize (this is also relevant to the digital to physical world interactions).

An important insight about agent harness is how it changes through use. 
Prompts, memory, skills, and routing rules becoming persistent state that agents can edit.

A domain specific harness can also accumulate experience. An agent might save a useful procedure, change an instruction after a failure, or adjust which tool it uses. Once those changes persist across sessions, they affect every task that follows.

This makes evaluation part of the domain-specific work. 
- A customer support agent might learn a faster resolution procedure, but does it still handle exceptions correctly? 
- A robotics agent might find a shorter sequence of actions, but does it still respect physical constraints?
Harness edits need a promotion gate.
The agent proposes a change, an evaluator compares it with the previous version on tasks that did not shape the edit, and the gate decides whether to adopt it.

My bet is that defining those tasks and acceptable tradeoffs becomes a large part of building for a domain. 
You need to know what success means, which failures matter, and what must keep working as the agent changes.

Each new model is a reason to re-evaluate the harness. 
Some instructions and workarounds may become unnecessary. 
Domain-specific evaluations help you decide what to remove and whether the simpler version still does the job.

The bear case for domain a domain specific harness? It's gonna be pretty hard for any harness to outperform a frontier team over time, especially if frontier teams have infinite compute on models that aren't publicly available.

Domain specific harness

I have been working on agent tooling for the last few months. Much of that work has involved tasks where both the outcome and the steps are clear. In those cases, choosing the tools in advance for the agents makes sense, you know what the agent has to do and you give access to the tools to accomplish the work (e.g. SEO improvements require access to GSearch console, [openSEO](https://github.com/every-app/open-seo) and a couple skills).

But when you know the outcome but cannot predict every step necessary to accomplish it, what then? Giving an agent a persistent computer lets it choose how to get the work done.

We keep designing agents around the assistant model: we choose the tools and prescribe how they should work. To me, this feels like skeuomorphism, carrying a familiar interaction model into a technology that could support something different.

![Early iBooks on iPad, with digital book covers arranged on wooden shelves](/blog/agents-love-computers/ibooks-bookshelf.jpg)

*Early iBooks displayed digital books on wooden shelves. The books no longer needed a shelf, but the familiar design helped explain the new medium. Source: [Glenn Fleishman, TidBITS, April 2010](https://tidbits.com/2010/04/05/reading-books-on-the-ipad-ibooks-kindle-and-goodreader/).*


The idea of agents using computers is already established. [Anthropic described this approach in 2024](https://www.anthropic.com/research/developing-computer-use). What interested me here is how to provide agents with a minimal Linux desktop that persists between agent sessions. Files should still be there when the next session starts. Separate profiles should have their own storage, and multiple agents should be able to work in separate desktops at the same time.

I also prefer running these environments locally. Website access is one reason. I have run into sites blocking access from data-center environments, which can lead to extra work configuring proxies. Running locally does not guarantee access, but it allows human takeover easily as well to unstuck the agent when needed.

I built HotDesk around these requirements. It runs in Docker on a local machine and provides desktop environments with separate profiles and persistent storage. I can ask an agent to use HotDesk for a task and keep its working environment available across sessions.

![HotDesk video demo](/blog/agents-love-computers/hotdesk-x-to-docs.mp4)

Try HotDesk on a task of your own. **[GitHub](https://github.com/jamalavedra/hotdesk)**.


Agents love computers

Every company has a know-how and a way of operating.
Capturing this knowledge is key, especially in big corporations where it is compartmentalized by default.

We shouldn't assume companies have the know-how built in.
Many seek independent advice (often consultants) for new ideas, improvements, optimizations.
As agents become prominent, they will benefit from knowing industry best practices and become the de facto **consultant** of sorts, especially in SMBs.

Let's assume for a second that knowledge and context are solved, I wrote about capturing knowledge in [the LLM software frontier](/blog/the-llm-software-frontier).
This one is about the other half.
How do we make it actionable, so it helps us proactively in the tasks we cannot automate away?

My attempt at a copilot is called Savvy, and [it's open source](https://github.com/jamalavedra/savvy).
Savvy is the smallest possible version of the "agent as a consultant".
It solves a particular pain I had: no matter how well I prepared for a call, I would either forget the method or the complete outline of things I wanted to mention during the conversation.

It doesn't join my meetings so it works with all meeting apps.
Most importantly, it bases the advice it gives off of the corpus you give it.
It can be either your personal know-how or some company-wide document.

The recommendations come from a simple brief document you can ask Savvy to generate or from a pre-made file you give it.
The brief is important because it distills the corpus into a single document. 
I find it useful when:
- In sales/negotiation calls I want to follow a specific process and techniques.
- I want to make sure to remember to mention something in a conversation.

Technically, Savvy uses your Claude Code subscription or your ChatGPT subscription for the live recommendations and either AssemblyAI or Deepgram for the live transcript.
It listens to the system audio and microphone and creates live recommendations of what you should or shouldn't say. 

Here's how it looks when listening to a sales call:

![Savvy demo](/blog/making-knowledge-actionable/savvy-demo.mp4)


*Acknowledgements*:
Savvy was created off of [handy](https://github.com/cjpais/handy).
Thanks to the amazing work of CJ Pais and contributors.

*Disclaimer*:
Goes without saying that telling others you're running a recording/transcribe service is mandatory.


A live call copilot grounded in your own playbook

Making knowledge actionable


We wanted one internal agent for the whole team. You give it a job in chat. It does the work and replies in the same thread. That job might be session triage, an analytics question, a policy lookup, a scheduled report, or browser work.

We built it three times in three months. Condor v0 ran on Cloudflare, v1 on Docker, and v2 now runs on Kubernetes. Rebuilding it this often was painful, but each failed design made the next one less naive.

## v0: agents as edge functions

```diagram
condor-v0
```

v0 ran entirely on Cloudflare. A chat webhook hits a [Worker](https://developers.cloudflare.com/workers/), which verifies the sender, normalizes the event, and routes it to a [Durable Object](https://developers.cloudflare.com/durable-objects/) keyed by chat thread. The Durable Object stores the turn log, budget counters, and session ID. It boots a [Container](https://developers.cloudflare.com/containers/) for the session through the `@cloudflare/containers` [Container class](https://developers.cloudflare.com/containers/container-class/), posts the turn to a small server inside it, and streams text and tool calls back to the thread.

Inside the container, the harness was either Claude Code or OpenCode.

I would build the credential design again. Every credential environment variable inside the container contains the literal string `credential-brokered`. A boot scan checks every variable against secret-shaped regular expressions. If a real key slipped in, the container aborts before the agent starts. The real values stay in [Secrets Store](https://developers.cloudflare.com/secrets-store/), bound to the parent Worker and never exposed to the container.

[Outbound traffic interception](https://developers.cloudflare.com/containers/platform-details/outbound-traffic/) enforces that boundary. The image trusts Cloudflare's certificate authority, and the Container class intercepts each request. The Worker checks a hard-deny list, then a default-deny allowlist. If the request passes, it replaces the placeholder with the real credential, forwards the request, and writes an audit row.

The rest of the state was scattered across Cloudflare products. [D1](https://developers.cloudflare.com/d1/) stored one audit row per egress decision. An [R2](https://developers.cloudflare.com/r2/) dead-letter bucket caught failed writes so we did not lose decisions. [Workers KV](https://developers.cloudflare.com/kv/) held the session bearer token and budget counters.

R2 also stored the agent's knowledge and skills as markdown. We packed the files with reproducible `tar` flags into content-addressed bundles and streamed the selected bundle through the Worker at boot. A nightly [Cron Trigger](https://developers.cloudflare.com/workers/configuration/cron-triggers/) built and published a new bundle hash. We could update the agent's knowledge without rebuilding its image or deploying it again.

Three things killed it:

1. A tight allowlist made the agent safe and much less useful. It worked for a bounded task such as "investigate this session." It fell apart on SEO work, which might need product analytics, Search Console, the CDN, the website repository, and whichever competitor pages mattered that week. We had built an agent we could trust, then discovered it could not do the work we wanted to give it.

2. The harness was baked into the image, so changing it required a rebuild. A container crash killed the session. State lived in Durable Object storage, KV, D1, an in-memory map, and container disk. We could neither rewind a session nor replay it against another model.

3. Running all of this on Cloudflare cost too much.

## v1: agents as an orchestrated swarm

```diagram
condor-v1
```

For the second attempt, we forked [agent-swarm](https://github.com/desplega-ai/agent-swarm) from [Desplega Labs](https://www.desplega.sh/) and moved to Docker. A lead agent received each request and delegated it to workers assigned to code, observability, sales, research, or support. If a worker died, the lead could spawn a replacement and keep the task alive. That recovery model was the best part of v1.

The host process held the database and every credential. Workers ran in short-lived containers. The bridge IP identified the spawn, and the spawn identified its role. Each role had a YAML manifest listing its allowed tools and hosts, plus the knowledge and skills mounted at boot.

Tool access passed through two independent MCP checks. `tools/list` trimmed the catalogue to the worker's role. It failed open because a bug there only exposed a longer menu. `tools/call` checked the role's tool list and argument policy, and failed closed. Seeing a tool was harmless. Calling one was not.

An HTTPS CONNECT proxy sat between each worker and the internet. It held a short-lived vault session minted for that spawn, enforced the role's egress allowlist, injected authentication into outbound requests, and scrubbed the responses. The worker could use a credential without possessing it.

One container meant one worker and one task. Every task paid for a full cold boot, adding 60 to 130 seconds before useful work began. About seven serial configuration fetches took 30 to 50 seconds even when the API was healthy. Three more round trips fetched the vault session, GitHub token, and harness credentials.

We had accidentally started building a container orchestrator. Capacity gates, heartbeats, reapers, warm pools, delivery receipts. The work was real and occasionally interesting, but none of it made the agent better at its job.

## v2: agents as a control plane

```diagram
condor-v2
```

On the third attempt, we stopped writing our own control plane. We now run `paradigmxyz/centaur` on Kubernetes, with our changes kept in a private overlay repository.

Its scheduler has the model v1 needed. A session is separate from its sandbox, and the scheduler assigns a sandbox only when execution begins. It claims a pre-booted pod from a warm pool, removing the cold start from the request path. Idle pods scale to zero replicas instead of being destroyed, then resume on the next turn.

A partial unique index in Postgres allows one active execution per thread, even across restarts. A node-level repository cache fetches updates every 30 seconds and mounts read-only into each pod. The session workspace runs `git clone --shared` against that cache. Each session gets an isolated worktree and a fresh branch without downloading the repository or copying all of its objects.

The harness is now an adapter. Each implementation only needs to translate content into the form its runtime expects. It may save images and documents as files, pass Anthropic content blocks through unchanged, or extract plain text for a CLI that expects one prompt. The pod receives prompt files, a CLI command, an internal API URL, the proxy certificate authority, and proxy settings. It receives no Kubernetes credentials or third-party keys.

Credential brokering carries forward the best idea from v0. The sandbox holds a literal placeholder, and a proxy pod dedicated to that sandbox replaces it with the real value on the wire.

## What actually generalizes

Start by brokering credentials at the network layer. Keep placeholders inside the sandbox. Inject real values on the wire, bound to an allowed host and request location. A compromised sandbox cannot leak a key that never entered its address space.

Cold starts change how people use an agent. When every task takes 60 to 130 seconds just to begin, people stop asking small questions. Claiming a warm pod and pausing it while idle improved the product more than another round of prompt tuning would have.

Put every event in an ordered session log. When state is split across five stores, you cannot rewind a session, replay it with another model, or reconstruct what happened after a crash.

Let the model choose its skills. We wrote two routers and regretted both. A substring matcher picked the wrong skill when words overlapped. A tool-call sniffer missed loads because the CLI injected the skill body as a system message without emitting a tool-call event.

Markdown skills packed into content-addressed bundles survived every version. Domain experts can edit them, and the agent can load a new bundle without a deployment. Most of the infrastructure changed in three months. Plain text did not.


what we learned building the same internal agent three times

Three attempts at an internal agent

Every new iteration of your favorite product is now a chat interface with a bunch of MCP integrations and a set of skills. 
Skills tell the LLM how to use the MCP effectively. 
These are what I call `tools`.

Creating a chat interface has become the easiest way of making your product agent native; it forces you to add what is needed for agents to use it.
In turn, it's now easier than ever to connect a few tools and add a chat UI on top.
To me, this means that products with pay-as-you-go pricing should be better placed to benefit from [the new AI wave of innovation](/blog/the-llm-software-frontier).

Products not creating tools fast enough become blockers for AI-native users, so I've created Douze.
A Chrome extension + relayer tandem that allows you to convert any site into an MCP + skills combo you can use in any AI of your choice.
Here's a demo on how it works:

![Douze converting a site into an MCP + skills combo](/blog/anatomy-of-an-agent/douze-demo.mp4)

Douze listens to network requests and catalogues what you do in a site. 
It creates a list of endpoints and descriptions on what they do and exposes them through a relay to hosted AI platforms.
[GitHub repo](https://github.com/jamalavedra/douze)

While the gap between the big model providers and the applications built on top becomes smaller, the gap between what coders can do and what non-technical people can do keeps widening.

For example, a coder wants to create a new outreach tool: create a new folder, add some tools for profile enrichment like Apollo, connect an outreach tool like Instantly and a CRM like Attio.
Voila, you have a sales agent tool better than 90% of what's out there.

The elephant in the room is whether specialized tools will be able to outcompete these home-baked alternatives.
Most importantly, if homegrown alternatives to popular software will be sticky enough.
Following the [Dropbox history line](https://news.ycombinator.com/item?id=9224), they should.

Providing 80% of the value of most tools out there with a layer on top of strict pay-per-use at 20% of the price should outcompete in an AI-competitive world. 
Providing provable, verifiable work at specific problems will also be valuable in a world where tokens stop being subsidized, e.g. data aggregation that allows for the agent to skip most research.


Anatomy of an agent

It feels like every other company now is battling over convincing clients to upload knowledge sources to their platform. It's understandable: LLMs' answers are only as relevant as the context they have on the question they seek to answer.

Context in this sense is the intelligence an LLM has over your product. It can be learned, and it's in the interest of every company to extract it from its most tenured employees such that it's persisted and permeated throughout the company. e.g. you want to capture what your best salesperson does, their workflows and automations, so other salespeople in the team can copy and learn.

Providing low-friction ways for companies to gain this knowledge is where it's at. The Schelling point then becomes the knowledge base and keeping it in sync. Then the key is how to deploy and use it with the right harness in each use case.

Each harness has its own third-party connections that augment the LLM's capabilities. Things the agents cannot figure out by themselves because they are dependent on the environment, so they need to know how to find/figure them out. I expect that most of these tools will be ripe for disruption if they don't adopt a pay-per-use strategy. For example:
- Social media planners need to schedule posts, find new innovative ways of conveying a message based on new trends, see analytics on their post performance, etc.
- SEO planners need tools to do keyword analysis, access to your analytics and Google Search Console to see how well you're doing, etc.

How can we best capture the company know-how? How is it shared across company teams with proper permissions and sandboxing and agent loops? The most interesting approaches to this come from low friction and high information density.

It's clear that tools that are first used to augment human work can then gain know-how on that specific application and automate it away. The key question is then, what can't be automated away? Right now that is work that requires judgement, or work where regulation prevents it. These are the sections where *copilot*-like tools will accrue most value, as they cannot be automated.


The LLM Software Frontier


*A look at how a JWT authentication vulnerability led to $400k+ in drained wallets—and what it reveals about the tradeoffs between frictionless UX and wallet security.*

Some thoughts on the [Kontigo app wallet vulnerability](https://www.kontigo.com/en/article/security-incident-postmortem-unauthorized-account-access).

## What happened

The attacker exploited a [vulnerability in Supabase's GoTrue auth server](https://github.com/supabase/auth/security/advisories/GHSA-9wqv-qhrh-87f4). By using an OpenID Connect compliant ID token issuer under their control, they could authenticate as any legitimate user.

This allowed the attacker to mint JWT tokens and impersonate 1,005 users, draining 340,905.28 USDT from their wallets.

Three days later, the attacker used pre-issued TEE wallet JWTs to drain an additional 56,913 USDC. The TEE trusted these tokens, which had a default validity of 30 days.

### Why JWTs matter for wallet security

How can a JWT lead to draining a wallet?

Most TEE-based embedded wallets require a valid user token to reconstruct the user's private key. A TEE wallet JWT is issued after verifying an incoming OIDC-compatible JWT against the configured JWKS.

The root of trust is in that token. If it's exposed or forged, you're cooked.

## How this could have been avoided

Require user interaction whenever they interact with the TEE to reconstruct the private key. This way, JWTs would not be the root of the trust.

Options include:
- OTP verification
- Passkeys
- Authenticator apps

This attack is a reminder that **frictionless always comes with trade-offs**.

### A note on custody claims

Is the Kontigo app a self-custody wallet? No, but now at least it's being called non-custodial in the post-mortem.

That claim is also questionable. Kontigo could mint access tokens via Supabase Admin endpoints on behalf of their users—tokens that would be valid to create new TEE JWTs.

## What this means for OpenSigner

Let me take these learnings home and apply them to OpenSigner: wallet security is a spectrum. Developers should be able to tune the friction of the wallets they provide based on the assets they secure.

[OpenSigner](https://opensigner.dev) is an open-source on-device signing solution based on SSS with 2/3 quorum. It supports 3 encryption methods for securing its cold share:
- [Password](https://www.opensigner.dev/actions/signup#password-recovery)
- [Passkey](https://www.opensigner.dev/actions/signup#passkey-recovery)
- [Automatic](https://www.opensigner.dev/actions/signup#automatic-recovery)

![shamir-secret-sharing](/blog/auth-jwt-wallet-vulnerability/sss-3.png)

For its relation to the Kontigo attack, I'll focus on automatic recovery. The other two methods would not be affected by a similar attack because user input is required by default.

### How automatic recovery works

Whenever a user creates or recovers their wallet on a new device, they must decrypt the cold share.

In automatic recovery, the developer is given an encryption share they must safeguard at all times. This encryption share is part of a 2/2 quorum encryption key required to encrypt the cold share.

![encryption-key](/blog/auth-jwt-wallet-vulnerability/sss-2.png)

By default, the system's root of trust is with the access token—it must be secured at all times.

The developer must expose a backend endpoint to create a one-time encryption session based on the encryption share they own.

This introduces a first barrier to a similar attack, because the developer can check that the request to create an encryption session comes from their own front-end.

To avoid the same pitfall where an access token could be forged, we developed an OTP-based solution that requires users to provide input to create the encryption session.

## Key takeaways

- **JWTs as root of trust are risky** — If your TEE wallet relies solely on JWT verification, a compromised auth layer means compromised wallets
- **Frictionless UX has security costs** — Every step you remove is a layer of protection gone
- **User interaction matters** — Requiring OTP, passkeys, or authenticator input during key reconstruction adds meaningful security

Building secure wallets means finding the right balance between convenience and protection. [OpenSigner](https://opensigner.dev) gives developers the tools to make that choice.

Some thoughts on the Kontigo app wallet vulnerability

When TEEs become insecure for private key operations


We hire people that we believe will be at the NYC stock exchange ringing the bell with us.

We have a growth mindset, everyone that joins in the beginning has the opportunity to get into a very high leadership position from within the company. 

There's a component to building a company that's different from just the transaction of paid by project. Rather, it's a camaraderie and really stark belief in the mission and projection of the company.

Communication is faster in-person. Everyone in the room will pick up by osmosis what's going on, which will translate into people innovating better.

Us being one of the few tech companies that are fully in person all in Barcelona opens a lot of access to the game studio community.

We manage plans to maximise productivity. 

We optimise for being on top of our game for health and learning. This makes it an awesome place to work.

In 10-15 years we hope to have achieved a significant amount of impact on the way people interact and manage digital assets.

The company has an intense work ethic. That's how we operate. Eventually, at scale, we'll have such a MOAT that we'll have a little more work/life balance.

If you want to join a seed stage company, and you actually want to be successful and win, there's going to be a lot going on in your profession, so you'll need to make some sacrifices in your personal life.

If you're at a point in your life where you want to lean into professional growth and trying to be the best that you can be, this is the place for you. We have an immense amount of mentorship from some of the best investors in the world. We are growing significantly fast, which unlocks a lot of opportunity to work on really cool, innovative projects. If you want to work hard, just like going to engineering school where you create relationships that last a lifetime, this is the place for you.

We're in the trenches, we're building together, and you'll have relationships that last forever (think PayPal mafia). That's the goal. While doing that, you're going to have a very positive impact that you can see in our customers' eyes while you do it.

Our core values:
- Dream big: a trillion-dollar company.
- Olympian work ethic.
- Growth mindset.
- Customer obsession.

[We're hiring](https://jobs.openfort.io/)

We hire ambitious, hard-working smart people.

Openfort's Work Ethic


A blockchain-native communication platform could foster collaboration between decentralized community members while allowing them to build their digital identity with their contributions. Decentralized communities could host hubs for their members, where each tokenized community features a Discourse-like discussion board.

## The problem: Decentralized communities are missing a native coordination layer

The current coordination infrastructure used by decentralized communities relies too heavily on traditional solutions. Solutions that look like enterprise SaaS instead of multiplayer. Why is that?

For one, the lack of alternatives makes the switch impossible. Communication tools like Discourse and Discord have been filling the gap for crypto communities with increasing numbers of apps and bots to power their communities or API calls to offer their centralized content.

We all know what happens when the tools we use depend too heavily on centralized players (See Aave Founder being blocked by Twitter or Bankless being blocked by YouTube).

Crypto-native communities deserve crypto-native software. User databases are siloed, there is no cross-chain reputation and solutions are missing on new frontiers enabled by crypto.

Decentralized communities remove the barrier for billions of internet users to trust and coordinate capital with anyone on the internet. More crypto-first coordination tools are required.

[A user on the MakerDAO Discourse](https://forum.makerdao.com/u/longforwisdom/summary).

The same user on multiple Discourse forums will lose all this information and start from scratch.

## A potential solution: Incentives on the social graph

A decentralized communication layer on top of the onchain social graph could add social, collaborative, and productivity components that, otherwise, would exist in different off-chain silos. Tools for feedback, voting and decision-making would emerge for every user.

An implementation could leverage Lens protocol to create a place where community members share and discuss relevant resources for the community. Some information would live on the blockchain while other data could be stored in IPFS.

## Vision

Social protocols will define how people organize and how culture flows by allowing digital-age coordination at scale. Open social graphs are the crypto-native approach to re-architecting the traditional tech stack.

## Moving from Enabler to Grower

Community tooling has evolved immensely in the past years. But there is a clear distinction to make when it comes to incentives. Tools designed as "Growers" help contributors take the next step, with modules to increase the value of the end-user.

The ability to own your contributions and bring your badges with you means that people can build their reputation on their own terms. The days of waiting for someone else to decide whether or not you are worthy of recognition are over.

With an open state database, everyone can see who has contributed what, how often they contribute, and how much value those contributions have created for others. This approach was not possible before because it would take too long for someone else to verify the validity of one's contributions using conventional methods like peer review or other forms of verification by third parties.

### Technical considerations

Building on Polygon makes sense due to its low-cost transactions. Even with Ethereum rollups where transaction costs are over $1, low-value transactions such as following and upvoting would not be economical.

Content management protocols like Ceramic (content storage on top of IPFS) and Lit Protocol (privacy via content access control) could manage and store content file data.

Using a social graph protocol like Lens allows the use of implemented core primitives in a composable fashion.

Lens is extendable and EVM compatible, which means that developers can add features on top of the core primitives. This approach is clearly distinct from social graph protocols like [DeSO](https://www.deso.org/) and the full stack application [gm.xyz](https://gm.xyz/)

## Growth strategy

A strategic starting point would be in the discussion for protocol-based communities. Protocol communities are the most resilient and active in the ecosystem.

Developing liquidity over scale early on matters. Building enough value for crucial communities to migrate operations to another platform at once.

## Key features

On-chain interactions bring novel ways to interact with community members. This is a novel approach to community-aligned metrics where contributors can [prove](https://twitter.com/StaniKulechov/status/1529544441303863296) and benefit from being actively involved. Developing an on-chain reputation through these interactions plays a key role for participants of any digital economy.

Unlike applications like Discourse that monetize through subscriptions, a blockchain-native platform isn't limited to the direct selling of licenses or subscriptions. Modules could be pre-configured to serve different functions, such as targeted airdrops based on the social graph, sentiment analysis on the community or access to gated sections.

Communities have to rely on tools like [SourceCred](https://sourcecred.io/) to encourage and activate their community by rewarding their most active users. Opening up collaborators to earn cash implies that economic value is not derived from speculation, but rather from *commerce.* This evolves into tipping capabilities or even curate-to-earn dynamics.

Once the social graph is formed, the relationships are unforkable, which cements the social graph in the network and attracts other protocols to service the revenues.

## Challenges

There is no doubt about how powerful open social graphs are. Owning your engagement and identity is a no-brainer for anyone starting the journey in decentralized networks. There are 2 challenges that need to be overcome:

 - Technological challenges. Any meaningful social network would produce significant transaction amounts that far exceed the current chain throughput. Because with Lens the state of every retweet, post comment, etc, is a transaction, there needs to be a sustainable model of gasless transactions through relayers. There are some open questions whether subnets or token incentives can balance out these costs.
 - User Experience. Blockchain apps have long relied heavily on the desktop experience. But mobile is by far the preferred way to access communication. Finding the optimal balance between connecting identities and engagement in decentralized communities will revolve around clean and intuitive products.


Exploring blockchain-native communication platforms for decentralized communities.

Decentralized community incentives



- Places where people have a big passion already but the economic models don't make sense.
- It's hard to keep living in the future. The mind wants to rest in the present. Inspiration comes in bursts.
- To get intuition on a certain topic, you need first to learn the rules upon which that field is based to then forget them.
- When you know that you can build it better, take the leap of faith if it won't happen without you.
- The most rewarding thing about my job is that I never have to work very hard to explain why I love it.
- Work on a super hard problem that no one else is working on.
- If you have to use someone else's name or authority to get your point across, there is little merit to the point (you might not believe in it yourself). If you believe in something to be correct, focus on showing your work to prove it. Authority derives naturally from merit, not the other way around.
- A platform is *composable* if its existing resources can be used as building blocks and programmed into higher order applications.
- If you mix two hard problems you get an impossible problem.


## Best founders
- MVP as a wedge into the market and then leverage that into a much larger opportunity.
- Timestamp the vision.
- Predict something non-obvious about the future of the world before others see it & make it market ready for their ultimate vision.
- Too many companies are money driven, end up making less money. Be positive impact driven.

## Analyse an idea
- If with a new technology:
	- Can only be done this way.
	- Take full advantage of the new technology/benefits.
- Motivation around the topic.
- Potential of the idea.
- Knowledge around the core technology.
- Capacity to attract top talent with the idea.
- Profit potential.
- Probability of success.
- Ever felt the problem.
- Do you like who the customer is.
- Can we have product led growth.

**On life's intrinsic motivations by [Daniel Pink](https://en.wikipedia.org/wiki/Drive:_The_Surprising_Truth_About_What_Motivates_Us)**
1. Autonomy → the urge to direct one's life.
2. Mastery → the desire to get better at something that matters.
3. Purpose → the yearning to do work in the service of something larger than one's self.

**On how to begin**
1. Where am I now.
2. The very next step forward.
3. The goal/dream.

## How to find a problem
- Reformulate as a question → bite off partial solutions off of it.
- Bring something inaccessible to the masses.
- Find the problem intolerable & feel like there must be a way to solve it.

**How to find something people want**
1. Something people use that's broken.
2. Turn luxury into a commodity.
3. Look at what big companies should be doing and then do it.

## Zero to one - Thiel
- Doing what we know how to do takes the world from 1 → n.
- College can teach you many things, but many don't know what to do with those skills.
- What important truth do very few people agree with you on? Many people believe in X, but the truth is Y. What companies is no one building?
- How do we go about developing the developed world.

-   Two types of progress: horizontal (1 to n) or **vertical (0 to 1)**
    -   Horizontal is focused on copying things that work and improving them
    -   Vertical is focused on breaking new ground
- Most common case of failure is when people don't get along. Far more than external competition.
-   “Competition can make people hallucinate opportunities where none exist”
-   Build + maintain a monopoly
    -   Monopolists lie to protect their monopolies — they make the markets in which they compete seem larger, to deflect attention; “everyone is competing with us” (Google has a monopoly on search and search advertising, but talks about being a broader technology player)
    -   Non-monopolists tell the opposite lie — ”we’re in a league of our own”; understating the true scale of real competition
-   Capitalism and competition are opposites
    -   Capitalism generates profits
    -   Competition eliminates profits
-   Definite vs. Indefinite / Optimism vs. Pessimism — a great 2x2 matrix for thinking about mindsets for innovators
- How to develop a good idea? Know a secret about your market. How to develop a secret:
	- Know the tools better than anyone else
	- Know the problems better than anyone else
	- Draw from your own experience background
- Get an understanding about something where other people do not yet have. The secret at PayPal they were very interested in cryptocurrencies and encryption technologies and currencies and could they be intersected. Can you build a new digital currency.
- Go after big markets that are growing a lot and capture as much of it as possible - one example of this is clean tech companies, where in the first slide they show a huge market- which will of course come with a lot of initial competition.
- What are the things that can be done in London better than anywhere else in the world.
- The advantages of Silicon Valley, like network effects, also have disadvantages like more lemming-like and crowd-like behaviour which can also be problematic.
- Work on a problem that otherwise would not get solved. An important problem where people have a blind spot around it or aren't thinking about it. Foundation about it - passion about it, at a psychological level - something that a lot of people are missing one way or another.
- A bad plan is always better than no plan.
- The future has to be thought of in concrete terms and has to be different from the present. Only with these two can the future have a charismatic force. Based on western Europe there're 3 possible futures on offer:
	- Islamic Sharia: women have to wear a burka
	- totalitarian AI a-la China: computers track you 
	- hyper environmentalism where you drive an e-scooter and you recycle.
- Where is the frontier? Where are the pockets of innovation where you can do some new things and not be in a crazed competition? What's a good career that other people aren't pursuing? -e.g. petroleum engineer-
- The most important thing: you need to have a **secret**.
- In an industry with a lot of incumbents, a lot of money, one has to have a projection of the future that nobody else agrees with that turns out to be insightful.
- You need to be able to track the future accurately. Otherwise you give generic advice and that's something that most people ignore.
- Most people hedge
- You must be looking where everyone else isn't. Otherwise there will be tons of competition and it'll be very hard to differentiate.
- What do you know that's true that nobody else understands.
- Tech startups are inherently a global business, so they must do one thing uniquely well, better than anyone else in the world.
- What great business exists that nobody else is building.
- Sometimes companies are iterations on things with one fundamental improvement in one key dimension.

## Previous successes
### Musk
Looked at the present, where the internet was, and thought about the obvious opportunity this was going to be. No rocket science, no genius. Seeing the truth when everyone is laughing and having math to prove it.

Next company, x.com (Paypal) -> putting your financial information on the internet. 
Trust your reasoning from first principles.

Reason from axioms vs reason by analogy. In the important moments in life you should reason from first principles.

See where it's going because he could see where it was that day. Conventional wisdom is still a few years later.

If this could be done, this would have been done a long time ago -> a math that you believe in. See reality, assess probabilities, ignore the rest/noise.

### Bezos
1. Saw web usage growing 2300% YoY.
2. Made a list of the top 20 products to sell online & picked the one that could only happen online.

For any infant technology -> Anything that can be done using traditional methods should probably be done that way.

Your best theories are going to be creative guesses, not simple speculations.

### Airbnb, Coinbase, Stripe
1. Timing was important:
	- Preexisting product.
	- Preexisting competitor.
	- 10x Better Product Possible.
2. Most founders and investors thought these ideas were terrible (either too hard to execute or plain bad ideas).
3. Each opportunity turned out to be bigger than what the founders expected.

## Axioms
GDP percentage of the west is in decline:
- Influence and capability to defend itself will also decline (although people will probably not notice this).
- Capability of states to crack down on civilians will increase -> people will try to look for alternatives.

The west is focusing more on equality rather than on excellence. Focus on defending universal values of:
1. Freedom of speech.
2. Free markets.
3. Protection from search & seizure.

## YC recommendations
-   What problem are you solving?
-   Can you state the problem clearly
-   Have you experienced it yourself?
-   Can you define your problem narrowly?
-   Is your problem solvable?
-   Who’s your customer?
-   How intense is the problem?
-   Are they willing to pay?
-   how easy are they to find? (The customers)
-   Does your MVP actually solve the problem?
-   Which customers should you go after first?
-   Which customers should you run away from?
-   Should you discount or start with a super low price?
-   How to set up metrics
-   GA + something else (Amplitude, Mixpanel)
-   Pick 5-10 important stats
-   Make measurements a part of a product spec
-   Product Development Cycle
-   KPI Goal

Bullet points and ideas that are relevant when evaluating startup ideas

Bullet points on evaluating startup ideas


Censorship resistance feels more like an edge case today.
Another way of thinking about it is in terms of digital property rights.

e.g. in the 2000s, the deal from social networks was amazing because you’d get free distribution to everybody, hosting, content creation tools…
Relative to the 1980s and 1990s when distribution was very scarce when being on TV was the biggest thing, now everyone is able to stream on YouTube, post on Blogger, post on Facebook or what have you.

But as time went on, this has become the standard package and what has happened, is that rather than being neutral platforms, they have a huge thumb on the scale. Downgrading in search results, YouTube Adpocalypse… people don’t have a share in what they are creating and don’t have control over their digital presence, which becomes more and more important as it becomes a larger percentage of your life.

An interesting question to ask: What percentage of your waking hours a day do you spend in front of a computer? That is more than 50% for many people, especially information workers.

Most of your remaining life will be spent in the Matrix, and if you don’t have root over the Matrix (if you can just be locked in a box and all the doors are closed and money is taken away, and you’re silenced), that’s actually possible if somebody has root.

Against being totally powerless, the alternative is to have control and have economic rights. Control means private keys, and economics also means private keys. It's both the freedom and the prosperity. People focus on the freedom in the sense of censorship resistance, but it is also the prosperity in terms of digital property rights.

Crypto creators will be so much bigger than Internet influencers because they will get a much bigger cut on what they create. Millions of people are not getting a cut of what they create. When they do, they will share so much more of it, and it's going to be more useful because they're going to do it in exchange for cryptocurrency and not simply likes, and so on.

One should appreciate how hard it is to build centralized companies and also appreciate that it is very difficult to have something where you got a loop that has been optimized for addictiveness for many people, and it’s taking so much time, and to have that compensated in some way. 

One bad part would be that things can become too transactional. On balance though there’s some good to that too. But even that can be positive, given that so much in social media currently is empty posturing and so much is hostility. This is because it would incentivize people to behave more positively when there are more mechanisms for economic alignment instead of a zero-sum status. But that is clearly a negative. Also, when everything has a price, you’ll see a lot of things that you didn't think about as being priceable, like sentiment (memes, hashtags) so you’ll be able to trade against that.

On balance, it’s good to add some degree of scarcity to the mix here because otherwise it is hidden, and it only exists as root in someone's servers, so instead put that back into people’s hands.

The single most important field is crypto identity (ENS, Solana names, Orbit …). We’ll need another term other than “Connect Wallet”, as it sounds like it will drain your money, but that portable identity is way more important than people think because when identity becomes portable, backends become liquid. When you can log in to a new service as easily as you load a new webpage, that means that the ice blocks (Twitter DB, Facebook DB), those become liquid and can flow between platforms, potentially as easily as just clicking. 

It's like the transition from analog to digital cameras. Even though they were worse than their counterparts, they were more convenient, so they got used a lot and improved a lot.

Once crypto identity hits that flippening, when it has millions of users, when services are built for that first (maybe around late 2030), then you can have for instance a crypto phone, and you have identity fundamentally with the private keys (all money, digital property), then digital exit becomes much more powerful because digital services need to fight for their bread because they don't have lock in.

The most scarce resources per decade:
- 2000 - Bandwidth
- 2010 - Attention
- 2020 - Blockspace
- 2030 - Loyalty

There needs to be Vampire attacks on web2 services like (Instagram, Twitter, Facebook). When tokens are integrated into social networks, they become more of a digital tribe.

In the west, people react with apathy and then panic.

The first web was the open web and Google could index that, it’s actually very difficult to do it, but it's possible with crawlers and so on (many technical difficulties in allocating the right bandwidth to each crawler and telling when should a site be recrawled - Cisco algorithms). Crawling is complicated because there are many formats, you have to do wrapper induction, it's a database populated page, how do you know you got all of it, how do you know you’re not breaking the web app when crawling it, etc.

The social web is even harder to index because it sits in Facebook's, Twitter's… servers and they don’t want to let you index it. LinkedIn actually lost the “hiQ” case where scrapers can now in theory index LinkedIn, but they are still not making it easy. In theory, you can do a data export but really it's not just data but also your identity and your connections - your social graph - as an individual (it's your community, your subculture).

What people don’t get about blockchains is that up until this point they have been basically hosting financial data. It didn't look like web1 or web2 data, meaning HTML pages or social pages. But now it's starting to as blockspace increases (DeSo, Mirror, Capsule Social, orbit, …). Essentially you have decentralized storage of posts and identity and other kinds of things. This radically simplifies indexing. One simple proof is that everybody can set up something like btc.com or blockchain.com or blockchair.com (block explorer), and already billion dollar companies have been built as block explorers (etherscan.com). Indexing is easier and therefore searching is also easier because instead of pinging the sites, and all the crawling complications, you get it all pushed directly to you with new blocks.

Now with people signing the content they create with the ens or other identities, you have digital signatures as a first class feature. That is huge, and they are open. 

A big chunk of Google nowadays are actually queries for many recent events. They don't show all the historical stuff - hard to find it. That means that their index is highly biased towards open state platforms (because they’re less than 1 year old). A large fraction of Google will move to new clients. They are much more vulnerable than what people think because the whole scope of what they index and the difficulty of indexing it may just get transformed. This is a redefinition of the problem because search has just become easier, it has got more signals, Google doesn't have the core competency around it.

New kinds of social networks will be built, and many of them will invoke finance as a first class feature (because you can assume that every user has a balance). The backend change to a decentralized social network is so challenging, that what people might just do is have almost exactly the same front end that we’re already accustomed to (client), and then put all the energy into innovating in the backend and making that actually work first.

Crypto creators will be so much bigger than Internet influencers

Balajis on distributed social networks


The bits that matter:

1. **Vision and mission**
2. **Speed**
3. **Product Customer Fit**
4. **Product Market Fit**


## Mission and vision

**Mission**: Why do you exist, other than making money? Higher-order purpose. Clear on what would be better afterward.

**Vision**: What does the future look like because of you?

Why do you need those things:

1. **Decision-making** if everyone knows the end goal there's less existential debate.
2. **Your brand customers** will know what ideas they're signing up to, what do you stand for?
3. **Your employees** you want a team inspired by the shared purpose, not just the revenue growth or monthly metrics.

## Speed

A startup is a business designed to grow fast. You should be moving at breakneck speed. You should be very uncomfortable with things moving at a normal and fast pace.

Companies that ship fast always outperform.

What are the ingredients of speed:

- Culture
- Tooling: Bring value to customers and increase our ability to do that fast.
- Focus
- Process

>Fast gets good before good gets fast


## Product customer fit

Your product must be **loved** before you can tolerate being **liked**

Forget all the hacks, optimizers, and multipliers. **Product Customer Fit** means that "for a given customer, do they use our product every time the problem occurs and does it solve the problem **<u>every</u>** time."

**Jobs to be done:** The more you understand the problem, the more the solution becomes self-evident. How to understand your job:

- **Interview your users**: Break the interviewees into different specific groups of people.

- **Scope your product:** Make a storyboard on why someone would start using your product. i.e., What happened so that you needed to start using our product, What did it feel like to start using our product, how did you know that our product was the right one for you, what was your definition of success, do you ever think you'll stop using our product. Use this to set up metrics that matter.

- Pick metrics that matter. The real question you want to know is, **do they use my product every time it matters**, meaning **what is the expected problem frequency or the trigger that causes me to use it.**

When X happens, I use Y, every X I use Y. How many unique users have fully adopted your product. Are you fully solving the problem? You have product customer fit when some amount of unforgiving customers use our product every time it can help them, and it solves their problem completely.

## Product Market Fit

You have a repeatable, reliable, and efficient way to reach the people who have the problem your product solves.

On the marketing funnel, you should start at the bottom with the happy paying customer and work your way up the funnel.

How people buy your product:

1. Problem-based: They search by the description of their problem.
2. Category-based: They search by the solution category.
3. Competition-based: They want a better version of what they currently have.
4. Brand-based: They want you!

**Disclaimer**: _These are a set of notes I took from listening to Des Traynor. They don't fully represent his thoughts as some of these might be rephrased to something I understand more clearly._


## Notes

1.  [Why startups succeed](https://www.youtube.com/watch?v=Oh4sA47XpR0)


Notes on what Des Traynor (co-founder of Intercom) has to say about startups

Des Traynor on why startups succeed

Just some random thoughts I got today after hearing the latest episode of King of Kings from Hardcore History. From its definition of ambition: "The earnest desire for some kind of achievement or distinction, such as power, honor, fame or wealth, and the willingness to strive for its attainment."

I have the intuition that remarkable individuals are born, sure. But they are also blessed by a set of circumstances that allowed them to develop their ambition to their full potential.

Before the information age, coined from the “Sovereign Individual”, it feels like the places where this person could appear were always constrained to what civilization happened to be in the eye of the hurricane. There are countless examples of this: Alexander the Great, Xerxes, Julius Caesar to name a few.

This is because even extremely ambitious individuals are constrained by the local maxima they believe plausible, therefore crippling their expectations.

Now in the information age, these hyper-ambitious individuals aren’t only constrained to where they live but rather have the possibility of learning what everyone else at the top of civilization knows, which in theory should make the likelihood of an extraordinary individual appearing from wherever. I’m not sure this is the case though.

I have the intuition that remarkable individuals are born, sure

About hyper-ambitious individuals


Zoom fatigue is a real thing. A lot of meetings are now lasting much less, like a turbo meeting of around 7 minutes. A lot of meetings are getting replaced by written culture (asynchronous communication). People just post and say what they are going to do that day, no need to meet every morning for a daily stand-up. People are finally realizing that reading is 2x as fast as listening, and if your culture really wants to speed up you move to a written culture, an asynchronous culture where business moves at the speed of thought.

We're realizing that we can just send a Google Doc that aligns our thinking and if we take the time to write it well, there's no point in talking. And that's time saved, even though it takes longer to write the doc, if it deletes the meeting, that's a win. There's still a bit of fallback to Looms where we narrate the piece, which is also working. People are trying to avoid meetings, it pisses people off.

Having meetings mainly for socialization. Avoiding and clarifying meeting slides through other async tools like Slack allows for higher-level discussions in the actual meetings. It's fascinating because people miss co-workers, and want to see them hang out. But, the fact that people are happier around their families on their own schedule makes a lot of companies double down on the work from home paradigm.

This clearly doesn't work for everybody. The effect that this has on mentorship for people that are young in their career will be something to be determined. At this point, changing companies is like changing between tabs in the same browser, because none of these policies are unique. The idea of company identity is lost and people are starting to regret this kind of stuff. All these evangelists that claim they know how to make hybrid work, still haven't figured it out themselves.

Moving to deliberate social gatherings is very valuable. Especially because they're an opportunity to replicate the camaraderie moments. The cost of leaving a job where you haven't met anybody and you have no fabric or real estate in the company other than the transactional nature of compensation is as low as ever. In a way, there's something lost there, as you didn't get a chance to bond with a group of people.

The written culture also forces a lot more for people to be self-managed (and have more ownership over what they produce), which means that the middle management roles aren't as necessary.

For people that will want to go back to the office, they'll let them go back. For remote and hybrid workers, I believe we need to make a distinction on performers. There are mainly three levels of performers in organizations:

- High performer
- Middle performer
- Low performer

Every company gets a percentage of each. For low performers between 10% and 20%. For anybody that is a real contributor, no one will care whether they're at home or office. For anyone in the middle that has the potential to become serial contributors, low average or below average, there's the possibility where a two-class system will come into play where for an average performance that has high potential and the company wants to invest in them, it might be hard to do that remote and wouldn't have the option. A-list players would get to pick, anywhere in the middle have to go to the office or the company chooses.

In the upcoming months, everyone is going to go back to the realization that workspaces have good air conditioning, nice food, and are purposely designed for work with nice meeting rooms. People are going to love it initially. The appetite is there, as the employees realize that designers optimize offices for work and there's something useful about that. So there'll be an initial storm back and that's fine. Still, fully remote workers will continue to be fully remote.

Companies will have to make a decision on what's the threshold for doing that, as you don't want a junior person that is super inexperienced and needs a lot of mentorship and wants to learn from the more senior engineers, it's going to be harder to do that from a bedroom somewhere.

The next stage is when everything normalizes, this 3 days a week thing is going to be complicated. That's because we're going to realize that we want a team on the same schedule. If there are 6 people in a room and a person on the dial-in, that's messy as they have different bandwidth conversations.

They'll need to agree on a schedule like, Mondays and Tuesdays they go to the office, and after that work is dished out and everyone knows what they're doing and there's no need to contact regularly (you move to async). Teams will need to set an operational cadence themselves.

I suspect it is going to be three months after everyone is back to normal that people are going to realize what we need to do. That moment is going to be a bundling between fully in-office, fully remote, or the hybrids (where they'll need to agree on the days).

You can't just dabble with remote, once the more senior people aren't in the office all the time, the shift to written culture becomes mandatory. It's either that or losing time in meetings.



We're realizing that we can just send a Google Doc that aligns our thinking

My thoughts on the future of work


Every software company that ever was, has always said, _“our product is intuitive and easy to use”._ The reality is that every one of them lies. Here’s what happens for a human to use software: from the thing that you want to do, you need to translate that intent into a set of actions (drag and drops and swipes) to make the software do what we intend to do. E.g. You’re in Photoshop and say that you want to remove the background, you should just be able to say “remove the background from this image”. If you’re in HubSpot you should be able to ask “how many people have signed up for our product in the last 90 days?"

You should be able to just type that question in because that is your intent. You should be able to express the thing that you want, and the technology should be able to figure it out. We have the technology now on the language side to be able to understand languages, and all we really need is a translation layer.

This is a megatrend-to-be, which is bigger than mobile. Mobile added the translation from what you used to do on your desktop, now you can do it from anywhere. And this enabled a bunch of new use cases.

This thing is: that thing that you have been trying to learn, that software layer you never got good at because you never had the time. Now a billion people can use that piece of software that wasn’t even possible before because they don't have to learn the clicks and drags to make it work. They can express the thing they want, and the software can do it.

If you were an enterprising VC, you'd be choosing the categories where this will have the biggest impact (business intelligence, reporting, B2B software is a natural fit). The beginnings of the consumer side would be with things like Alexa, but the B2B world is open to making the thing actually intuitive and make it do what I want.

That magic trick → You just do this and that and get the result that easily. Like waving a wand and getting a surprisingly good result. Once you see it, you can’t unsee it. So that when you see it, you can’t look at the products that don’t have it in the same way.

Google is kind of this magic genie where if you give it a set of questions, it tries to come up with the answers. If this can actually be done, this is the next level to Google in that you can ask it any question, and it doesn’t just give a set of pages where the answers might be, but it actually tells you the answer.

It turns out that many tools out there (Google Calendar, Microsoft Word) all have internal APIs to build plug-ins around them. So there is a sophisticated way to control these tools with these internal APIs. Today, if you want to make new more complicated behaviors from these products, you need to add a new button for every new behavior. It is possible to use Codex and tell, for instance, your calendar to schedule a meeting next week after 2 pm. It would then write the corresponding piece of code, which is the thing that you ultimately want. No need to hard code each interaction, but rather Codex can take each API on the fly.

Every software company that ever was, has always said