Marketing: port X articles to the blog, add a testimonial

apps/marketing/src/content/blog/i-dont-want-to-use-your-agent.md

@@ -0,0 +1,56 @@
+---
+title: "I don't want to use your agent"
+description: "I want to use the skills, knowledge, and APIs your company has spent years developing, not your custom agent. How to enable power users without abandoning everyone else."
+date: 2026-06-27
+author: "Rhys Sullivan"
+---
+
+I want to use the skills, knowledge, and APIs your company has spent years developing, not your custom agent.
+
+Almost every company by this point has shipped an agent. There's a Cloudflare agent in their dashboard, a PostHog agent, a Mercury agent, a Linear agent, the list goes on. Each week we see a homepage fall to a chat interface.
+
+I don't actually think this is a bad thing, quite the opposite. Interacting with sites through an agent is magical.
+
+The problem is, I don't want to use any of these, for a variety of reasons.
+
+## Incentives
+
+One of the biggest is the incentive problem. I am always running Opus 4.8 or GPT 5.5. The costs for a company to provide this for free for all their users is unsustainable.
+
+What ends up happening is most of the time when you're chatting with an agent on a website, you're dealing with a quantized version of Kimi 2.5, and while it gets the job done, it's not your agent.
+
+I'm paying for the best models. I want to use the best models for my work.
+
+## Context
+
+When I am in the Linear agent on the web UI, it's lacking the ability for me to bring in my local files, random git repositories, etc.
+
+They can go build this functionality and are, but you're never going to beat me running my local setup.
+
+## So, what do I want?
+
+I want my agent to become an expert in your product and problem area.
+
+For Linear this looks like a set of skills to help me break down my largest problems into actionable tickets.
+
+For Cloudflare this looks like detailed docs on their extensive product surface and CLI commands to run.
+
+For PostHog, this is the data to query, deeplinked UI components to help me visualize data, skills to help me grow my product.
+
+The same knowledge and expertise that you embed into your UI and documentation needs to become accessible to my daily driver agent.
+
+## Enabling this
+
+The problem is, I am a power user of these tools. I have multiple Max subscriptions across different providers, am swapping tooling constantly. I am not representative of most users.
+
+So how do you enable the power users of this technology while not forgetting about the people that genuinely do want to use your in-app agent, Slack bot, etc?
+
+You build your internal agent off of the same primitives your power users will be using. This roughly looks like:
+
+- Some form of harness (pi, OpenCode, a harness SDK, can be lightweight)
+- Skills
+- MCP / API
+
+When landing on a chat, have some form of prompt that's like "want to continue in your own agent? install the MCP/CLI and skills."
+
+Your regular users can dismiss it and keep using your built-in chat. Your power users can embed your product directly into their agent. And you only have one source of truth to maintain.

apps/marketing/src/content/blog/mcps-apis-clis-are-not-three-separate-concepts.md

@@ -0,0 +1,57 @@
+---
+title: "MCPs, APIs, and CLIs are not three separate concepts"
+description: "They are all ways to invoke tools, that's it. How I think about tool calling, the different specifications, when to use each, and the underlying concepts."
+date: 2026-06-26
+author: "Rhys Sullivan"
+---
+
+MCPs, APIs, CLIs, are all ways to invoke tools. That's it.
+
+The goal of this article is to help share how I think about tool calling, the different specifications, when to use each, and the underlying concepts.
+
+As a thought experiment, consider what happens when you convert an MCP to a CLI. The actual underlying tools have not changed. All that's changed is your execution environment.
+
+Hammering this point again: context bloat is not an MCP problem. It is a problem of the implementation of how tools are exposed to the model.
+
+If a company has an MCP server, you want it to have as many tools as possible, as that's more capabilities your agent is able to do on your behalf.
+
+My personal [executor.sh](https://executor.sh) instance has ~10,000 tools in it, a mix of MCP and APIs, and agents are able to work beautifully with it.
+
+So, with it established that they're all the same underlying concept, why do these three exist? When do you use one vs the other?
+
+## MCP
+
+MCP seems to be the right protocol to use for any interactions that are with agents. Some examples of this:
+
+- [Claude Channels](https://code.claude.com/docs/en/channels-reference) is built on MCP and allows you to push data back into a running session via an MCP.
+- [MCP Apps](https://x.com/WorkOS/status/2059718408590245900) allows for embedding UI directly inside of chats, i.e. "show me a chart of my PostHog data."
+- [MCP Elicitation](https://x.com/RhysSullivan/status/2021043465119989916) enables getting actual input from humans. This is really useful when you need them to confirm something like "are you okay with analytics" or going to a URL to perform an action.
+- [MCP Triggers](https://modelcontextprotocol.io/community/working-groups/triggers-events) to notify clients of state changes.
+
+Now the trouble with these is there's a chicken and egg problem. Most clients only implement support for MCP tools and that's it. What's cool though is you can actually work around partial client support by doing the same functionality over tool calls only as a fallback, which I'll have a longer post coming on.
+
+## APIs
+
+Where I'm landing on APIs is they're great for raw data access and quickly converting your app to be agent accessible. APIs carry good information already about their descriptions, what operations are destructive / not destructive / etc.
+
+To me, it doesn't make sense to try to get behavior like MCP Apps, elicitation, triggers through OpenAPI, as that's not meant to be for agents. MCP is.
+
+## CLI
+
+This is going to be controversial, but I really think that CLIs are just for humans when looking at the long term horizon. A big part of this comes down to the known action space of a CLI, in that for people that want to know what an agent is actually able to do.
+
+The other part about CLIs is requiring a Unix shell to run them. When we look at enabling every person in the world to have a personal assistant or interact with their data through AI, the overhead of CLIs very quickly makes this not possible.
+
+That's not to say that they're bad though. I would easily argue the CLIs produced by [@steipete](https://x.com/steipete) are state of the art for agents because of how much care has been put into the design of their interfaces, their ability to get data in hard to reach places, etc.
+
+Today CLIs provide the best debuggability, interfacing, data access, etc. to agents because of the beautiful composability of bash and everything running them locally on your computer enables.
+
+[Back in March](https://x.com/RhysSullivan/status/2030903539871154193) we saw a lot of writing around "building CLIs for agents," and fundamentally it just comes down to bash being the wrong primitive for agents to be using. There's too many footguns for them to get trapped in, i.e. when they run a command that prompts for human input.
+
+## Closing
+
+At the end of the day, you can convert an API into an MCP into a CLI back into an MCP back into an API.
+
+They're all the same concept: giving the agent the ability to invoke tools. What changes is the amount of dependencies and capabilities the agent gets when using it.
+
+APIs are probably fine for 90% of applications. CLIs are the best for agents today just due to the robustness of bash. MCP has a lot of potential to solve the problems presented by using CLIs today. However, it's going to require spec improvements and good harness implementations, so hopefully Fable comes back.

apps/marketing/src/content/blog/we-are-not-using-enough-inference.md

@@ -0,0 +1,47 @@
+---
+title: "We're not using enough inference"
+description: "We're going to look back on the amount of inference we used in 2026 as laughably small. Some exploratory thinking about what a world of free, abundant attention looks like."
+date: 2026-08-09
+author: "Rhys Sullivan"
+---
+
+We're going to look back on the amount of inference we used in 2026 as laughably small.
+
+In order to properly read this article, you have to assume two things are true:
+
+- The cost of inference is going to 0.
+- Agents will be good enough to autonomously review changes, merge code, and act.
+
+So, what does this world of infinite high quality inference look like? Exploring some examples.
+
+## React2Shell
+
+The moment this CVE announcement was made, every Next.js site should have been instantly upgraded by an agent.
+
+What's interesting here is attackers will also have lists of every Next.js site on the internet maintained along with autonomous attacker agents. The same agents that are good enough to autonomously upgrade sites are also good enough to exploit them.
+
+Defenders are in a significantly worse position than attackers here. Whatever autonomous fixes that are being deployed need to not break production or cause more security issues. Defenders have to be close to perfect, attackers just have to find a gap.
+
+## OpenAI x Hugging Face security incident
+
+If OpenAI had another LLM that was monitoring either the traces coming out of the evaluated LLMs, monitoring what was being written to the package manager, monitoring the network logs, they would've been able to catch the security incident before it became a problem.
+
+## Session replays
+
+It's not just security that you can throw inference at. Every session your users have on your site can be recorded and checked for issues on where users get confused, where layout shift or jank occurs. All of these problems are measurable and solvable.
+
+## Closing
+
+What to think about here is essentially when you hit a problem in your day to day, whether that problem could've been solvable or detectable by throwing more inference at it. The answer is likely yes.
+
+The XZ Utils SSH backdoor was detected because an engineer noticed a 500ms delay in SSH. So many problems are detectable and solvable but go unnoticed due to a lack of attention. When that attention is free and abundant you're able to solve these problems.
+
+A lot of bottlenecks have been on attention and hours in the day. Your session replays only have relevance if people watch them. Now you've got agents that are able to.
+
+There's a ton of problems this world creates as well. Where are these autonomous agents running? What credentials do they have access to?
+
+On deployment, are these agents deploying autonomously to production? If so, incremental rollouts are likely needed, feature flags, instant rollbacks, etc.
+
+I hear the screaming about the problems with agents autonomously deploying, but my prediction is that the model capabilities will become so good, it will actually be irresponsible to be bottlenecked on human engineers to solve these problems. If it takes 10 minutes for your engineer to be paged at 2 am, wake up, review a PR, send it live vs 1 minute for an agent, in a world where there's automated attackers the 10 minute window becomes significantly more risky.
+
+None of our tooling today is really built with this unlimited inference world in mind, but as model capabilities rapidly improve it will need to be too.

apps/marketing/src/content/testimonials.ts

@@ -85,6 +85,12 @@ export const testimonials: readonly Testimonial[] = [
     id: "2036226001877999868",
     text: "Really like what Rhys is working on with executor. I think it or something like it is probably the future",
   },
+  {
+    handle: "thesherlocker",
+    name: "Sherlock",
+    id: "2100071527811354813",
+    text: "Okay, this is really cool, I don't know why I've delayed my adoption so much. Executor is now my default",
+  },
   {
     handle: "BenceRedmond",
     name: "Bence Redmond",