AI companies received 82.7% of the deal value. The remaining 17.3% was split across everything else. Even that distinction is too broad, because an enormous round for a model company and a first check into a small AI startup both end up in the same category.

The conversation around venture tends to swing between “funding is back” and “funding is dead.” I don't find either particularly useful. A record tells me how much money moved. It doesn't tell me how many founders had a realistic chance of receiving any of it.

The biggest rounds tell us surprisingly little about everyone else

The biggest AI companies can raise sums that used to be associated with public markets. Their capital needs are real: computing infrastructure, research, talent, and distribution are expensive. A large round in that category can move the total for an entire quarter.

That doesn't tell us much about a seed-stage healthcare startup, a hardware company, or an enterprise software team without an obvious AI label. Even within AI, money flowing to a handful of model and infrastructure companies doesn't mean every application startup can raise easily.

If I'm trying to raise a seed round, I care about whether investors who understand my category are writing checks at that stage. I care about what evidence they expect and whether the company I want to build fits the outcomes they need. The industry can deploy another hundred billion dollars without changing those answers very much.

The investor side is concentrated too

The same PitchBook-NVCA Venture Monitor reports that funds of $500 million or more received 78.1% of U.S. VC fundraising dollars through Q3, despite making up just 6% of funds closed. First-time funds received about 4.5%.

That matters because a smaller fund can have a different set of interests from a very large one. A check or an eventual exit that would be meaningful to one fund might barely register for another. A newer manager may also have a different network or a reason to spend time in a category that established firms have overlooked.

None of that makes a first-time manager automatically better. It does mean that concentrating fundraising in large, established firms can change the range of companies venture is set up to support. It also doesn't mean a useful business has no financing options. Revenue, angels, smaller funds, and other sources of capital still exist. But “there is more venture money than ever” is a poor substitute for understanding which of those options actually fits.

I would rather know how widely the money is reaching

I'd rather know how many companies are raising a first round, how many get to a second, and whether that is happening across a wider range of sectors. I'd also want to know whether exits are returning money to investors, because that affects their willingness to commit to the next fund.

The total is still useful. It shows that investors are willing to commit extraordinary amounts to certain opportunities. I just think we should be much more careful about turning that into a statement about what it feels like to raise money right now.

Its RobFlow 8 release moved the platform onto ROS 2. It also introduced guided vision-based calibration and a beta OPC UA server that lets factory software read robot state. Those sound less exciting than a robot learning a new task. They may be closer to what gets one deployed.

I keep coming back to how much work a robot creates for the people who have to maintain it. You can watch a very impressive video without learning whether the factory team can recalibrate the thing themselves, or whether they have to wait for a specialist every time something changes. You also don't learn much about how it talks to the equipment and software already in the building.

Those details affect how much useful work the robot actually gets through. I think they will have a lot to do with which robotics companies become good businesses.

Someone still has to get this working in a factory

A manufacturing task sits inside a larger process. Parts arrive in a particular way. Another machine needs to know when the robot has finished. Operators need to intervene safely. Maintenance teams need to diagnose failures, replace a component, and resume without guessing what happened to the work in progress.

Better models can help with some of this. But if the production system cannot tell what the robot has done, or the maintenance team cannot work out why it stopped, improving the model alone leaves quite a lot unresolved.

RobCo's OPC UA support is a concrete example. It exposes robot information in a form that manufacturing execution and supervisory systems can consume. Its guided calibration feature addresses a different deployment problem: keeping physical movements aligned with intended positions as equipment and conditions change. I like seeing those things in a release because they address the work a customer has to do after deciding the robot is worth trying.

The two software pieces do different jobs too. ROS 2 is the foundation RobFlow runs on. The OPC UA server lets factory systems read information from the robot. Using ROS 2 underneath does not, by itself, make all the existing factory software understand what the robot is doing.

I would want to know what the second installation looks like

The first installation proves that a team can get the robot working somewhere. I'd want to know how much of that work carries over to the second customer, and the third. How much custom engineering does each site need? Can operators resolve common problems themselves? What happens to uptime once the pilot team leaves?

If those answers improve with each installation, the company has a way to make deployment easier as it grows. If every site needs another substantial engineering project, selling more robots may also mean taking on much more work.

More capable robots expand the range of tasks worth automating, which is exciting. I just think the adoption question is much more practical than a lot of the discussion makes it sound. A factory has to live with the robot after buying it. How annoying that turns out to be will matter.

That changes how I think about the time agents are saving. Getting a first implementation used to take enough effort that it naturally limited how many changes a team could have in flight. Now I can get to that point much faster. Someone still has to understand the change and decide whether it belongs in the system.

A study of 278,790 review conversations across open-source projects found that human reviewers exchanged 11.8% more rounds on AI-generated code than on human-written code. That's one study, and open-source review is not every company's workflow. But the direction makes sense to me. A plausible implementation can still miss the reason a system works the way it does.

The same people still have to review all of this

Imagine five engineers each using agents to produce twice as many pull requests. If the team still has the same two people who understand the tricky parts of the architecture, those people become the queue. The team may report more code written while changes spend longer waiting, or while reviewers skim to keep up.

I don't think asking those engineers to read faster gets us very far. We have to make the changes easier to evaluate. A pull request should say what behavior is meant to change, what constraints matter, how it was tested, and what could break. Smaller changes help, but only when each one has a coherent purpose. Ten tiny PRs with a hidden dependency between them can be harder to review than one clear change.

Tests and static checks can take some work off the human reviewer. They cannot decide whether a new abstraction fits the product, whether an edge case matters to customers, or whether a migration will be safe in production. A passing test suite is useful evidence, but I would still want someone who understands the system to examine those decisions.

I would want more of the thinking to happen before the code

When an agent is given a vague request, the reviewer can end up working out the requirements after the implementation already exists. At that point, someone has to explain why the code needs to change, and then review the next version too. We have made producing the first version faster without necessarily reducing the work needed to agree on what it should do.

For consequential changes, I'd rather have the engineer specify the expected behavior, boundaries, and failure cases before implementation. Give the agent the existing patterns to follow. Require evidence for claims like “backward compatible” or “safe to retry.” Then use review to examine the decisions that remain, rather than reconstructing what the author intended from a diff.

This also changes how I'd measure the benefit of coding agents. Lines written and pull requests opened tell me very little. I'd look at time from idea to a change safely running in production, review wait time, rework, incidents, and how often the same senior engineers are pulled into every decision.

I would be fairly skeptical of a productivity claim that stops at how much more code the team is producing. If the same people are spending more time reviewing, answering questions, and fixing problems afterward, some of the work has simply moved. I want to know whether the team can get a useful change into production more easily, and whether maintaining it becomes easier too.

The agent may have made the right decision to pay. The supplier is legitimate, the invoice is due, and the amount is correct. We still have a problem, because nobody on our side can yet establish what happened after the request left.

I spent about five years at Chime, and this is the kind of thing I find myself thinking about when I see agents taking on financial work. I want to know what happens when a response goes missing, or when one part of the task succeeds and another fails. Payments teams have spent decades dealing with those situations. Giving an agent the ability to call an API brings it into the same set of problems.

There are two kinds of action to account for. Credits, fee waivers, and balance adjustments can happen on your own ledger. Payouts, purchases, and transfers may also involve outside providers. A workflow can include both. Internal service calls can time out too, but with an outside provider, your own database can't establish whether the other system has committed the action.

The infrastructure for agents to transact is already arriving. In May, AWS previewed AgentCore Payments, which lets agents pay for digital services within enforced spending limits. As agents gain access to more financial operations, I'd want the following practices built into the systems they use.

A timeout does not tell us whether the money moved

For a vendor or seller payout through a bank API, a timeout leaves the result unresolved. The payment could have succeeded, failed, or still be in progress.

The integration needs a defined way to recover. Depending on the provider, that might mean looking up the operation or retrying with the same idempotency key and unchanged request. If neither option can resolve the uncertainty safely, the operation should stay unresolved and be escalated for investigation.

An agent shouldn't be able to turn “I don't know what happened” into a fresh instruction to move money. The system executing the transfer needs to enforce that distinction, including when another agent takes over the work.

It has to remain the same payment when the agent tries again

An idempotency key lets a provider recognize repeated attempts at the same operation. The application should create and store that identity before execution, then reuse it across retries and restarts.

For an invoice payment, that means retaining the link between the approved payment and its attempts even if the model describes it differently on a later run. A newly generated memo shouldn't create a second payment. A changed amount or destination requires a new authorization decision.

Some instructions produce several movements. A supplier payment might require funding the paying account first; a payout batch includes multiple recipients. Give each movement its own identifier linked to the approved instruction, so recovery can pick up the unfinished work.

Provider guarantees have limits too. Stripe, for example, can remove idempotency keys after at least 24 hours. Your operation history needs to outlast the provider's retry window.

Starting over can make a partial failure much worse

An agent processing an order reserves inventory and charges a card, then crashes before confirming the order. Starting over could create another charge or reservation. Recovery needs the identities and outcomes of the steps already attempted.

Save the authorized operation durably before execution, then record each step and its result. Temporal's model is a useful reminder of why external actions still need to be safe to retry: activities run outside the replay path and can be retried.

The same issue appears when a supplier payment succeeds but the accounting update fails. Recovery should mark the invoice paid using the existing payment record. Restarting the entire task risks sending the money again.

Cash reservations need care too: release funds only once the payment is known not to have been sent or has been definitively rejected. An unresolved payment may already have consumed those funds, so releasing them could allow them to be spent again.

I would want to know what “complete” actually means

An internal transfer within one ledger can post its debit and credit together in a database transaction. External payments have their own lifecycles. An ACH payment marked completed can still be returned, and a successful card charge can later become a dispute.

The system needs to follow those later events and update its records and messages accordingly. An agent that submitted a payment should report the status it can establish, including any uncertainty about arrival.

For a batch of payouts, track each recipient separately. Some payments may be complete while others need attention. Recovery should continue with the unresolved items.

Each agent can follow its instructions and still exceed the budget

Consider a purchasing agent with a $10,000 budget. Two workers can each see that balance and each try to spend $8,000. The service executing purchases needs to check and reserve the budget atomically. Asking the model to remember the cap won't prevent that race.

Authority matters beyond the amount. An agent might be allowed to move money between a company's own accounts but have no authority to send it to a new beneficiary. A support agent might be allowed to waive one eligible fee, without permission to make arbitrary balance adjustments.

The executing service should check the source, destination, amount, currency, and permissions. Human approval needs to remain tied to those exact details across retries. Treasury transfers may also need to leave enough in the source account for upcoming obligations.

We still have to check the records against what actually happened

For agent-initiated payouts, match the expected movements and ledger entries against the bank's records. A batch may appear as one bank debit and many recipient payments. Fees or currency conversion can make a simple amount comparison insufficient.

Modern Treasury separates completion from reconciliation: its completed event reflects bank execution, while a separate reconciled event reports the match to a posted transaction. Those are different facts for an agent to act on.

The CFPB's case against Synapse shows the cost of inadequate records. The bureau alleged that Synapse failed to maintain accurate records of consumer funds and ensure they matched its partner banks'. The banks identified a $60 million to $90 million shortfall, and consumers lost access to their money for weeks or months.

Internal actions need checks too. A fee waiver or account credit should have the corresponding ledger entries even when no money moves through a bank. Differences need an owner who can correct the books, trace a transfer, or investigate with the provider.

Agents make it easier to lose track of the original instruction

These problems exist in conventional financial software too. Agents add another place where an instruction can be reinterpreted, regenerated after an error, or handed to a different worker. The authorization and operation history need to remain consistent through those changes.

I would want someone investigating a problem to be able to follow the original instruction through the attempts, the actual movement, and the accounting records. That includes seeing what remains unresolved. If a different agent picks up the task tomorrow, it should be able to find the same history.

This is the part I would spend more time on before giving agents broader access to financial operations. Being able to submit a payment is useful. Being able to work out what happened to it, and recover without creating another problem, is what makes me comfortable relying on the system.

The data is already messier than the demos. METR's 2025 randomized study had experienced open-source developers work on repositories they knew well and found that they took 19% longer when AI tools were available, even though the developers believed AI had made them faster. METR tried to repeat the experiment with newer tools and said in February 2026 that the newer data was too affected by selection effects to give a reliable estimate, although it did suggest that tools had improved. Google's 2025 DORA research is more positive, finding a relationship between AI adoption and higher delivery throughput and product performance, but it also still finds a negative relationship with delivery stability.

That does not mean AI coding is useless. I use it constantly and it obviously changes what one engineer can attempt. It means that writing code is only one part of the production function. A model can generate a patch quickly, but someone still has to decide whether the patch solves the right problem, fits the architecture, introduces weird failure modes, can be operated in production, and should be merged at all. METR recently had maintainers review AI-generated patches that had already passed SWE-bench's automated grader and found that roughly half still would not have been merged. A 2026 longitudinal study of professional engineers also found a shift away from code creation and toward what the authors call supervisory engineering work: directing, evaluating, and correcting AI output.

That is the org-design problem I find more interesting. If implementation gets cheaper but verification, architecture, product judgment, and coordination do not get cheaper at the same rate, then the scarce resources on a team move. The team should be designed around those scarce resources rather than around how many people can physically type code.

In the pre-AI model, it was normal to think about capacity in engineers. A squad with six engineers could take on more implementation than a squad with three, even if the relationship was never perfectly linear. With agents, the unit gets fuzzier because one engineer can have several implementation threads moving at once. But that does not mean the team can safely accept several times as much change. Review queues can get longer, test failures can multiply, architectural inconsistency can creep in, and the number of things somebody has to keep in their head can increase faster than the useful output does.

I think this argues for smaller teams only when the surrounding system is strong enough to support them. A mature codebase with good tests, clear service boundaries, safe deployment, useful observability, and an internal platform that makes the right thing easy is a much better candidate for a small agent-heavy team than a tightly coupled system with slow feedback and a lot of tribal knowledge. DORA's 2025 work makes a similar point: high-quality internal platforms are strongly associated with organizations getting more value from AI.

It also changes what I would optimize for in the humans on the team. I want engineers who can own a problem end to end, decompose it well, give an agent enough context to do useful work, recognize when the output is subtly wrong, and make good tradeoffs when the requirements are ambiguous. Technical depth still matters, but the value of judgment goes up when producing another implementation is cheap. The person who can generate five patches is less useful than the person who knows which two should exist and can tell whether either is actually safe.

That does not mean every team should become a collection of senior engineers. I already think senior-heavy teams have their own problems, and AI can make the opportunity problem worse if all of the interesting judgment work gets concentrated in the most experienced people while everyone else becomes an agent operator. Junior and mid-level engineers still need real ownership, debugging experience, design work, and chances to build taste. If we automate away every piece of work that used to teach those skills, we eventually create a team full of people who are very good at supervising systems they never learned how to build.

The manager and technical lead roles change too. If an engineer can have three or four agents producing changes in parallel, review capacity and change coordination become things you have to manage deliberately. I would rather have fewer concurrent changes with clear ownership than maximize the number of agents running. The goal is not to keep the model busy. The goal is to move a coherent product or system forward without creating a pile of verification debt for the humans.

This also changes how I would measure whether a smaller AI-native team is actually replacing the output of a larger pre-AI team. Lines of code, pull request count, and agent task completion are almost useless for this. I would look at how long it takes to get a meaningful change from decision to healthy production, how much review time it consumes, how often it gets rolled back, what happens to incident rates and support load, whether the system stays maintainable, and whether users actually get more value. If those things improve with fewer people, then the team really is more productive.

My guess is that the near-term win from agentic coding is not going to be "every engineering team can immediately be half the size." It is more likely that good teams can hold headcount flatter while taking on more scope, or that a small team can own something that previously would have required a larger one if the architecture and tooling are already good. In messy systems, AI may just let us produce mess faster.

So I would not start team design with a target headcount reduction. I would start by asking what work remains scarce after code generation gets cheap. Right now that still looks a lot like judgment, context, review, architecture, product understanding, and operational responsibility. The smallest useful engineering team is not the smallest group of people that can generate the code. It is the smallest group that can carry all of those things without quality collapsing.

I went in somewhat skeptical because it is Meta. Meta has enough history around privacy that I am not naturally inclined to hand it more personal information (though I have technically been a W-2 employee of theirs- can’t really get more personal than that). To its credit, Muse is designed around a dedicated secure VM, encrypted credential storage, approval before sensitive actions, and controls over which services it can access. Meta has made privacy and security a fairly central part of how it is positioning the product.

I still have reservations about trusting Meta with that much context. But as a product, I liked Muse. Then I tried to use it.

Ultimately, you’re in the web’s house

One of the things I asked Muse to do was close an old Etsy store of mine. This was not an ambitious task. I was doing some personal housekeeping and had an old store I no longer needed. It was exactly the kind of annoying, low-value administrative task I want an assistant to take off my hands.

Muse got blocked. That changed how I thought about the product pretty darn quickly.

The interesting part of an agent is not that it can tell me how to close an Etsy store. A chatbot could already do that. The interesting part is that I can say, or should be able to say, “Please take care of this,” and stop thinking about it. If the agent gets to the site and cannot proceed, a lot of that value disappears.

Muse is already running into this problem elsewhere. Less than two weeks after its launch, Amazon blocked Muse from accessing its shopping site. Amazon has also taken a restrictive stance toward other third-party shopping agents. This is probably not going to be an isolated fight.

I have started thinking about my own automations differently

I am currently in the market for a car. I have an agent workflow that automatically checks for new listings matching what I care about and sends me the interesting ones. It is useful because I do not have to repeatedly search the same sites. I can define what I want once and let the software watch for changes.

A few months ago, I would have thought mostly about whether the workflow was reliable. Now I also find myself wondering how long the underlying access will continue to exist. Maybe the listing site changes its markup. Maybe it rate-limits automation more aggressively.

Maybe it adds a bot challenge. Maybe it decides agents are bad for its business model and blocks them outright.

My automation currently works. I am basically waiting for the day it does not.

The current generation of agents depends heavily on infrastructure they do not control. The browser is theirs. The model is theirs. The agent loop is theirs. The website is not, which matters more as agents become capable of doing useful things.

When bots mostly indexed the web, sites had a fairly legible relationship with them. Search engines crawled pages and sent people back- but agents are different. An agent can potentially sit between the customer and the site. It can compare products without showing the customer the full storefront. It can bypass carefully designed upsells. It can transact without the person seeing an ad. It can decide which vendors the user ever encounters.

From the website’s perspective, that is not necessarily an uncomplicated win. I may want my assistant to shop across twenty stores for me. Each of those stores may prefer that I arrive personally. That tension is going to matter a lot for users.

Capability is not the same as usefulness

A lot of AI discussion still focuses on model capability. Can the agent reason through a task? Can it use a browser? Can it fill out a form? Can it recover when something changes?

An agent can be perfectly capable of completing a task and still be unable to do it because the service on the other side refuses access. The assistant gets smarter, but the environment becomes more hostile. We may end up with agents that can theoretically do almost anything a person can do online while being permitted to do a much smaller subset of it. The growing gap between capability and permission is starting to look important.

We are adopting and abandoning products incredibly quickly

There is another part of this I find interesting. The agent ecosystem is moving so quickly that my relationship with software feels less durable than it used to. A new product appears. It solves something I care about. I spend a few days imagining all the workflows I can move onto it. Then a model changes, an API changes, a site blocks it, the product changes direction, or something better appears. I move again. The adoption cycle is incredibly fast, but so is the abandonment cycle.

That makes it difficult to know how deeply to integrate any of these products into my life. Muse is a good example. I liked it enough that I immediately started looking for boring tasks to hand over. Within days, I was also seeing the boundaries of where it could operate. That does not make Muse a bad product. It makes the environment around Muse unstable.

I am not sure where this ends

There are several plausible outcomes. Sites could build official interfaces for agents and decide exactly which actions they want to allow. Large assistant platforms could negotiate direct integrations one company at a time. Payments standards and identity systems could make agents more recognizable and trustworthy to websites.

Some sites may simply decide that third-party agents are useful distribution and welcome them. Others may insist that users interact through their own assistants. We could end up with something that looks a little like the mobile app ecosystem, where the dream of a broadly interoperable layer gradually turns into a set of controlled platforms and bilateral integrations. I do not know yet.

What I do know is that I am becoming more cautious about treating agent capabilities as durable. When I see an assistant perform an impressive task now, my next question is increasingly not just “can it do this?” It is “who has to keep allowing it to do this?” That feels like a much more consequential question than it did even a few weeks ago.

KEDA is not a GPU scheduler. It does not decide which accelerator a Pod gets or where that Pod should land. It helps answer a simpler question: how much work should we be running right now?

For a normal web service, CPU might be good enough. For inference or batch workloads, the thing you actually care about could be requests waiting, tokens waiting, queue depth, latency, or jobs that have not started yet.

KEDA already works well with that kind of signal. ScaledObjects can scale Deployments and StatefulSets from external events and metrics. ScaledJobs can create Jobs as work shows up. If the signal you want is not built in, KEDA also supports external scalers.

People are already trying this with GPUs. A recent CNCF post used a KEDA external scaler to scale on GPU utilization, memory, temperature, and power draw.

I think the more interesting version is when KEDA scales on the work itself, and the cluster handles the hardware underneath it. That second part is getting better quickly. Kubernetes Dynamic Resource Allocation is now stable and gives the cluster a richer way to describe and allocate devices such as accelerators. Kubernetes 1.37 also made DRA-backed extended resources generally available, so workloads can keep asking for familiar resources like GPUs while DRA handles the allocation underneath.

A node provisioner such as Karpenter can handle another part of the problem by adding capacity when the cluster cannot place the workloads it already has. So I would not make KEDA understand the whole accelerator stack. I would let it stay focused on demand.

The application knows whether there is work piling up. KEDA can turn that into more or fewer Pods and Jobs. Kubernetes can figure out which hardware can run them. The node layer can decide whether more machines need to exist.

Where this gets fun

An inference service could scale on requests waiting instead of CPU. A batch system could create GPU Jobs as items arrive instead of keeping workers sitting around. A model with sporadic traffic could scale to zero and let expensive GPU nodes disappear when there is nothing to do.

It also gets more useful as clusters become less uniform. We are moving toward environments with different GPU models, partitions, memory sizes, and other accelerators rather than one big pool of interchangeable hardware.

KEDA does not need to understand all of that. It can ask for more work to run. The lower layers can decide how to place it.

There are still hard problems below that boundary. Multi-node training, gang scheduling, topology, device placement, and accelerator allocation are not things KEDA solves.

But that is kind of the point. KEDA can stay simple while the hardware layer gets much more sophisticated. I think that gives us a pretty nice way to build autoscaling around what the application actually needs instead of trying to make one layer understand everything.

No product. No customers. No obvious distribution. Maybe not even a clearly defined problem yet.

You have to decide what to make, who it is for, why they should care, how to reach them, what to charge, and whether the market is real before there is much evidence to guide you. That is a very specific skill set.

We talk about entrepreneurship as though people are either entrepreneurial or they are not, but I think that collapses several very different capabilities into one label. Some people are unusually good at finding an idea in a messy market and turning it into something real.

A lot more people seem good at taking something that already has a goal, customers, constraints, and some evidence of demand, then making it better. Those are not the same job.

Zero to one asks you to invent the map

The hardest part of starting from nothing is that almost everything is ambiguous at once. You can spend months building the wrong thing.

You can solve a real problem for a market that is too small. You can find a good market and still pick the wrong distribution channel.

You can get early users who like the product but will never pay enough for the business to work. There is no scoreboard yet.

Even deciding what progress means is part of the work. That is where a lot of otherwise very capable people struggle.

Give them a team, a target, some existing customers, a messy process, and a set of constraints, and they can make enormous progress. Give them a blank page and ask them what company should exist, and they freeze.

I do not think that means they are less entrepreneurial. It may mean they are better at a different phase.

We already know this happens inside companies

This distinction is obvious when you look at larger organizations. There are people who are excellent at taking a product from 100 customers to 100,000.

There are operators who can improve margins, build a sales motion, make an organization more reliable, introduce better systems, or turn a chaotic process into something repeatable. There are leaders who are much better when the objective is concrete.

Give them a clear goal and enough room to operate, and they are very good at finding the path. This is not lesser work.

In many companies, it is the work that actually creates most of the value after the initial idea survives. But entrepreneurship still tends to romanticize the person who comes up with the idea in the first place. That biases people toward starting from zero even when zero is the part they are least suited to.

Browsing small businesses changed how I think about this

I did not always feel this way. Part of what changed my mind was spending time looking through businesses for sale on places like Acquire.com and Flippa.

What surprised me was not just the volume. It was the variety.

There are the obvious small SaaS businesses, but there are also profitable newsletters, e-commerce stores, courses, content businesses, agencies, directories, and tiny service businesses. I even saw tarot reading businesses.

That matters because it broadens the idea of what "buying a business" can mean. I used to think about acquisition entrepreneurship mostly in terms of buying a traditional small business or doing a search fund.

But there is a much wider range of businesses where the core question is not "can I invent something from scratch?" It is "can I understand why this already works and make it work better?" For some people, that is a much more natural question.

Existing traction changes the problem

Buying a business does not make entrepreneurship easy. You can still overpay.

The revenue can be fragile. The seller can be more important to the business than they admit.

A traffic source can disappear. Customers can churn.

The numbers can look much better in a marketplace listing than they do once you actually inspect the business. But you are starting with information.

There is already a product. There are already customers.

There is usually some evidence of what they are willing to pay for. There may be a distribution channel that already works, even if it is underdeveloped.

You can see where the bottlenecks are. That changes the nature of the challenge.

Instead of simultaneously inventing the market, product, and business model, you can spend more of your energy on diagnosis and improvement. Maybe the newsletter has strong engagement but weak monetization.

Maybe the store has good products but terrible retention. Maybe the course sells consistently through one channel and has never tried another.

Maybe a service business has demand but the operating process is still entirely manual. Those are scaling problems. A lot of people are very good at scaling problems.

This is especially interesting for people who want to be entrepreneurial but do not have an idea

There is a weird assumption that wanting to run a business should come with an original business idea. I do not think those things are necessarily related.

Someone can be great at product, operations, marketing, finance, sales, or execution without being particularly good at noticing unmet markets. They may also be bad at choosing between ideas because there is no external signal yet.

That person can spend years saying, "I would love to do something entrepreneurial, but I do not know what to start." Buying something changes that starting point.

The market and the existing customers have already made at least part of the decision. The question becomes whether you can make a good business better. That seems like a much larger pool of people.

The idea is not that everyone should buy a business

I am not trying to push people toward acquisitions. Some people genuinely love zero-to-one work.

Some people should absolutely start from scratch because their best advantage is seeing something before anyone else does. Some people would hate inheriting someone else's product, customers, or constraints.

And a bad acquisition can be much more expensive than a bad side project. I just think we treat "starting a company" as the default expression of entrepreneurial ambition when there are other paths that may fit more people.

The more I look at small businesses, the more obvious that feels. There are a lot of existing things that are not broken.

They are just underdeveloped. And there are a lot of people who may never be the person who comes up with the idea, but who would be extremely good at taking something with real demand and making it much larger, cleaner, or more durable.

That is still entrepreneurship. It just starts at a different point on the curve.

That is a great setup. The problem is that the book keeps turning every emotional beat up to maximum volume.

Louisa does not just meet the artist behind the painting. She meets him when he is dying. He does not just talk to her about art. He leaves the painting to her. She does not just learn who the teenagers in the painting were. She ends up traveling with Ted while he tells her the story of this intense, formative group of friends and everything they survived together.

And the past timeline is full of the same kind of escalation. Joar is living with a violently abusive father and starts carrying a knife because he thinks killing him may be the only way to save himself and his mother. Kimkim is closeted, isolated, and hiding drawings that he thinks nobody will understand. Ted loses his father. Christian, the school janitor who encourages Kimkim's art, dies. Ali eventually drowns. Even the story of how Kimkim gets a chance at art school involves the friends breaking into a museum to hang his work themselves.

Any one of those things could carry a novel. In My Friends, they stack.

Backman is clearly interested in friendship as something almost sacred: the people you meet young can save you, wound you, shape your entire life, and live inside everything you make afterward. I actually like that idea. I also liked the connection between the painting and the ordinary moment it captures. The point is not that the sea is beautiful. The point is that the people sitting together are the thing that matters.

But the book kept telling me how much it mattered. That was where it lost me.

There are scenes I probably would have found genuinely moving if the story had given them a little more room. Instead, grief leads into sacrifice, which leads into another revelation, which leads into another life-altering act of friendship. By the end I felt strangely less emotional than I did near the beginning because I had started anticipating the next attempt to devastate me.

I can see why people love this book. If you like Backman's very open, sentimental style, there is a lot here.

For me, it crossed over into melodrama often enough that I could see the machinery. I liked what My Friends was about more than I liked My Friends.

For that reason, I would put the agent on the proposal side of the deployment boundary rather than the production side. In a GitOps environment, the agent can interpret a request, inspect the repository and the operational context it is allowed to see, propose a narrow change, and open a pull request. CI and policy systems validate the artifact, humans or automated approval rules decide whether it should merge, and Argo CD remains responsible for reconciling the approved desired state into the cluster. This is less about distrusting AI than it is about preserving a control model the organization already understands.

The architecture I would want looks roughly like this:

issue / alert / deployment request
              |
              v
         agent runner
              |
              |  proposes a change
              v
        branch + commit
              |
              v
         pull request
              |
       +------+------+
       |             |
       v             v
   CI checks     review / policy
       |             |
       +------+------+
              |
              v
            merge
              |
              v
        config repository
              |
              v
           Argo CD
              |
              v
       Kubernetes cluster

The strategic point is what is deliberately missing from the left half of that diagram. The agent does not have a kubeconfig, it does not call kubectl apply, and it does not need permission to call argocd app sync. Argo CD already knows how to watch Git and reconcile the application after the desired state changes, so I would keep execution inside that existing control plane. The Argo CD CI documentation already treats updating Git as the normal deployment path, and an explicit sync call is unnecessary when automated synchronization is enabled.

At the implementation level, a simple Application for this pattern could look like this:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: payments
  namespace: argocd
spec:
  project: production

  source:
    repoURL: https://github.com/example/platform-config.git
    targetRevision: main
    path: environments/prod/payments

  destination:
    server: https://kubernetes.default.svc
    namespace: payments

  syncPolicy:
    automated:
      enabled: true
      prune: false
      selfHeal: true
    syncOptions:
      - ApplyOutOfSyncOnly=true

I would probably start with prune: false for an agent-authored path unless there were a strong reason not to. Updating an image or changing a resource limit is one class of action; deciding that a resource should no longer exist is a different blast radius. That distinction matters at the policy level because one of the easiest mistakes in agent adoption is granting an entire capability just because the platform supports it.

The config repository itself does not need to become more complicated because an agent is involved. I would prefer to keep the structure boring and make the agent operate inside an explicit surface area:

platform-config/
  apps/
    payments/
      base/
        deployment.yaml
        service.yaml

  environments/
    staging/
      payments/
        kustomization.yaml

    prod/
      payments/
        kustomization.yaml

  ci/
    validate-agent-diff.py

For a routine deployment, the agent may only need to change an image reference. That is a much easier action to reason about organizationally than granting a generic "deploy" permission because the proposed state is reviewable before anything reaches production:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - ../../../apps/payments/base

images:
  - name: ghcr.io/example/payments
    newName: ghcr.io/example/payments
    newTag: 9f13c42

I would also treat agent-created changes as a distinct trust class in CI. The point is not that an agent is inherently malicious. The point is that generation is cheap, so it is easy to produce a syntactically valid change whose blast radius is much larger than the request that triggered it. A company-wide agent strategy should define the kinds of changes agents are allowed to propose, not just the systems they can technically reach.

For example, even a very small policy check can demonstrate the boundary:

# ci/validate-agent-diff.py

from pathlib import Path
import subprocess
import sys
import yaml

ALLOWED_PREFIX = "environments/prod/"
BLOCKED_KINDS = {
    "ClusterRole",
    "ClusterRoleBinding",
    "CustomResourceDefinition",
    "Namespace",
}

changed = subprocess.check_output(
    ["git", "diff", "--name-only", "origin/main...HEAD"],
    text=True,
).splitlines()

for filename in changed:
    if not filename.startswith(ALLOWED_PREFIX):
        sys.exit(f"agent may not modify {filename}")

    if not filename.endswith((".yaml", ".yml")):
        continue

    with Path(filename).open() as f:
        for doc in yaml.safe_load_all(f):
            if not doc:
                continue

            kind = doc.get("kind")
            if kind in BLOCKED_KINDS:
                sys.exit(f"agent may not create or modify {kind}")

            pod_spec = (
                doc.get("spec", {})
                   .get("template", {})
                   .get("spec", {})
            )

            for container in pod_spec.get("containers", []):
                security = container.get("securityContext", {})
                if security.get("privileged") is True:
                    sys.exit(
                        f"agent may not enable privileged mode in {filename}"
                    )

print("agent diff is inside the allowed deployment surface")

That is not meant to be a complete Kubernetes security policy. In a mature environment I would rather express durable rules in an existing policy system, but the principle is the important part: the agent gets a defined change surface. It should not be able to turn "update the payments image" into "also modify a cluster role and create a privileged container" just because both actions happen to be possible through the same repository.

The corresponding CI job can remain conventional, which is another reason I like this design. The organization does not have to invent a second deployment system for agent-authored changes; it can reuse the same validation machinery and add narrower controls where needed:

name: validate deployment change

on:
  pull_request:
    paths:
      - "environments/**"

permissions:
  contents: read
  pull-requests: read

jobs:
  validate:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Install Python dependencies
        run: pip install pyyaml

      - name: Apply agent-specific policy checks
        if: contains(github.event.pull_request.labels.*.name, 'agent-authored')
        run: python ci/validate-agent-diff.py

      - name: Render production manifests
        run: |
          kubectl kustomize environments/prod/payments > /tmp/rendered.yaml

      - name: Client-side Kubernetes validation
        run: |
          kubectl apply \
            --dry-run=client \
            -f /tmp/rendered.yaml

The agent workflow itself should have Git permissions, not deployment permissions. In the simplest version it can create a branch and a pull request, but it cannot bypass branch protection or directly mutate cluster state. That keeps the model replaceable and prevents the agent framework from becoming part of the production control plane:

name: deployment agent

on:
  workflow_dispatch:
    inputs:
      request:
        description: "What deployment change should be proposed?"
        required: true

permissions:
  contents: write
  pull-requests: write

jobs:
  propose:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Run deployment agent
        run: |
          python tools/deployment_agent.py \
            --request "${{ inputs.request }}"

      - name: Create branch and commit
        run: |
          BRANCH="agent/deploy-${GITHUB_RUN_ID}"

          git config user.name "deployment-agent"
          git config user.email "deployment-agent@example.com"

          git switch -c "$BRANCH"
          git add environments/
          git commit -m "Propose deployment change"
          git push origin "$BRANCH"

          gh pr create \
            --base main \
            --head "$BRANCH" \
            --title "Agent-proposed deployment change" \
            --body "Generated from: ${{ inputs.request }}" \
            --label "agent-authored"
        env:
          GH_TOKEN: ${{ github.token }}

I left the model-specific implementation inside deployment_agent.py on purpose. Whether the company uses one model provider, an internal model, or a more elaborate tool-calling framework should not change the deployment trust model. If the AI layer can be swapped without redesigning production access, the architecture is less coupled to today's agent stack.

The same separation applies when the agent needs operational context. GitHub Actions can use OIDC to obtain short-lived cloud credentials instead of storing long-lived keys, and the role can be limited to the metrics, logs, or metadata the agent needs to inspect. The GitHub OIDC documentation is useful here because the workflow identity can be constrained by repository and workflow claims rather than sharing a permanent AWS credential.

I would also make the approval model risk-based rather than treating every agent-authored change the same way. Image updates and bounded configuration changes may eventually be good candidates for automatic approval if the organization has enough confidence in its tests and policy layer. Cluster-scoped RBAC, namespace deletion, CRDs, network policy changes, production database changes, and anything that materially expands privileges should have a different path. The company should decide those boundaries deliberately rather than letting the agent framework define them by accident.

For multi-step deployments, I would keep sequencing declarative where possible instead of teaching the agent an imperative production runbook. Argo CD already supports hooks and sync phases, so a migration that must happen before an application rollout can remain part of the declared deployment:

apiVersion: batch/v1
kind: Job
metadata:
  name: payments-migrate
  annotations:
    argocd.argoproj.io/hook: PreSync
    argocd.argoproj.io/hook-delete-policy: HookSucceeded
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: migrate
          image: ghcr.io/example/payments:9f13c42
          command: ["./bin/migrate"]

Argo CD runs PreSync hooks before applying the normal sync resources and stops the sync if the hook fails. From a leadership perspective, that is the kind of separation I want: the agent can decide that the desired state should include a migration, but the existing deployment system owns sequencing, failure behavior, and reconciliation.

The broader company decision is not whether agents are capable of deploying software. They are. The more important question is whether introducing agents requires us to discard the controls, auditability, and separation of responsibility we already built around production. I do not think it should.

If the agent is wrong in this model, the failure mode is usually a failed check, a rejected pull request, or a proposed change that never merges. That is a much better organizational default than turning a reasoning error directly into a production incident. The technical design follows from that leadership choice: let agents interpret intent and accelerate proposals, but keep production authority inside systems whose behavior and blast radius the company already knows how to govern.

It is easy to understand why that would completely destabilize someone. What I had a harder time with was how often Burden seemed completely helpless in situations where, from the outside, she appeared unusually equipped to ask better questions.

She is not someone who had never encountered contracts, money, or powerful institutions. She went to Harvard Law School and worked as a corporate lawyer at Davis Polk. That does not mean she should have understood matrimonial law or predicted that her husband would leave her. But it made some of her choices harder for me to understand.

The prenup is the clearest example. Before they married, James pushed to change their agreement so that income earned during the marriage would remain separate unless it was deliberately put into joint ownership. Burden's own lawyer advised her against the change. She signed it anyway.

Then, over the course of the marriage, she used money from her family trusts to help buy their New York apartment and Martha's Vineyard house and put both properties in joint ownership. James, meanwhile, kept much of what he earned in his own name.

She also let him take over the family's finances. Again, I understand how these things happen inside a marriage. Trust is the point. You do not make every decision while imagining how it will look in a divorce proceeding twenty years later.

But Burden actually had more warning than most people do. She had a lawyer telling her the agreement was a bad idea. She had legal training herself. She knew enough to be uncomfortable with the prenup change, and by her own account she avoided talking about it with people who might have challenged her decision.

That is where my sympathy started running alongside frustration. The same thing happened with the book's treatment of privilege.

Burden is very explicit that she grew up with enormous advantages. She comes from an extremely wealthy, prominent New York family. The marriage includes a Tribeca apartment, a house on Martha's Vineyard, private schools, inherited trusts, and a level of financial insulation most people going through a divorce could not imagine.

She knows this. But there were still stretches where she seemed surprised by how power worked until it was being used against her.

The pandemic setting makes this especially visible. Her family escapes New York to an isolated house on Martha's Vineyard while hospitals in the city are overflowing. Burden acknowledges how lucky they are. At the same time, the book is so tightly centered on the collapse of her own sense of safety that the surrounding crisis often feels like scenery.

I had a similar reaction when she starts reexamining the women in her family after James leaves. Her grandmother and other women she grew up around had endured infidelity, silence, and unequal marriages. Burden begins to see that history differently once the same kind of betrayal happens to her. That reflection is one of the more interesting parts of the memoir, but I also kept thinking: you had been surrounded by examples of this your entire life. Why did it require your own marriage exploding before you really questioned the arrangement?

That is probably the contradiction at the center of the book. Burden's privilege protected her from a lot of consequences, but it may also have made certain systems feel benign because they had mostly worked for her. A husband managing the money could feel like being taken care of. A traditional marriage could feel safe. A restrictive prenup could remain theoretical. The social expectation that women absorb unpleasant things quietly could look like good manners.

Then the marriage ended, and all of those things suddenly looked different. One of the strongest realizations in the book is Burden's eventual understanding that what she had experienced as protection could also be control. I believed that realization. I just sometimes wished the memoir pushed harder on why someone with her education, resources, and access to advice had been so willing not to look.

None of that made the betrayal less awful. Her husband's behavior after the affair is cold enough that the book becomes genuinely difficult to put down. The abruptness of his departure, his refusal to give her a satisfying explanation, and the transformation from husband into legal adversary are all unsettling. I also respected that Burden does not turn him into a cartoon villain. She spends a surprising amount of time trying to understand what happened rather than simply prosecuting a case against him.

But I did not come away from Strangers thinking primarily about the danger of women trusting their husbands too much. I came away thinking about how easy it is not to question a system when that system has mostly made your own life comfortable.

Burden eventually questions a lot of it. I just found myself wishing she had done so before it happened to her personally.

That is a real advantage. I am still not convinced the acquisition was the best move for Cursor as a product.

Obviously, I understand why the founders and investors would take the deal. A $60 billion outcome is an extraordinary result for a company that is only a few years old.

But the thing I valued most about Cursor was not that it had its own model. It was that Cursor sat above the model layer.

Cursor benefited from not having to pick a winner

One of Cursor's strongest positions was that it could simply use whatever model was best. OpenAI gets better at one kind of coding task? Use OpenAI.

Anthropic gets better at long-running agents? Use Claude.

Google ships something better? Add Gemini.

Cursor can train its own models where that makes sense and use third-party models everywhere else. That is a very attractive position in a market where the underlying models keep leapfrogging each other.

The product does not need to predict who wins the model race. It just needs to make the best models useful.

I think that neutrality was strategically important. Once Cursor is owned by SpaceX, which now has its own AI ambitions through xAI, that position gets more complicated.

Even if Cursor continues offering competing models, it is no longer an independent layer sitting above them. There is now a parent company with a very obvious interest in making its own models better and more widely used.

That does not mean Cursor will suddenly become a Grok-only product. It does mean the incentives have changed.

The compute argument is compelling, but it cuts both ways

The acquisition announcement talks heavily about compute. Cursor says SpaceX gives it access to the largest fleet of GPUs in the world and will let it build stronger models at lower cost.

That matters. Model training is expensive, inference is expensive, and coding agents are increasingly doing long-running work rather than producing a few autocomplete tokens.

Owning or having privileged access to large amounts of compute can materially change the economics. But I am not sure Cursor needed to become part of a model company to get that benefit.

It could buy compute. It could sign infrastructure partnerships.

It could raise more money. It could continue using external models while selectively training its own. Those options may be more expensive, but they preserve something that is difficult to get back once it is gone: strategic independence.

I think Cursor's application layer may be more valuable than its model layer

There is a tendency right now to treat model ownership as the highest form of defensibility. I am not sure that is true for Cursor.

Cursor built an unusually good interface between developers and models. It understood codebases.

It built the workflows around editing, agents, context, review, and iteration. It became the place where developers could benefit from model competition without having to care very much about which company trained the model underneath.

That relationship with the developer is incredibly valuable. The models may become more interchangeable over time.

The workflow does not necessarily become interchangeable. If that happens, owning the developer surface could be more strategically important than owning another frontier model.

That is why selling Cursor to a company with a model agenda feels strange to me. The independent version of Cursor could have been the Switzerland of coding models. The acquired version has a home team.

There is also a trust question

Developer tools occupy a weirdly sensitive position. Cursor can potentially see a huge amount of a company's source code, architecture, internal systems, and engineering behavior.

Enterprise customers already care about where that data goes and which models receive it. Adding a large parent company with its own AI business does not automatically make Cursor unsafe.

But it does add another question to procurement. Who ultimately controls the product?

What incentives does the parent company have? Will model selection remain neutral?

Will data boundaries remain exactly the same over time? Those questions existed before. I think acquisition makes them more salient.

The obvious counterargument is that independence was going to get harder anyway

Cursor is competing against some of the best-capitalized companies in the world. OpenAI, Anthropic, Google, Microsoft, and others all have strong incentives to own more of the developer workflow themselves.

The coding assistant is becoming too important to remain a peripheral feature. An independent Cursor would have had to keep paying for models and compute while competing with the companies selling it those inputs.

That is not a comfortable position either. SpaceX gives Cursor capital, compute, distribution, and the ability to train models without being completely dependent on external providers.

I can see the strategic logic. I just think the price of that security is higher than the acquisition announcement makes it sound.

The founders probably made an excellent decision for themselves

I want to separate two things that often get collapsed. A great acquisition outcome for founders is not necessarily the same thing as the best long-term outcome for the product.

Selling at $60 billion is an astonishing financial result. If I were sitting across the table from that offer, I am not going to pretend the decision would be easy to reject.

But from the perspective of Cursor itself, I think something important was given up. Cursor had become valuable partly because it did not need to belong to any particular model company.

It could be the layer that benefited no matter who won underneath. Now it belongs to one of the competitors.

Maybe the compute advantage ends up mattering more. Maybe Cursor becomes dramatically better because it can train models at a scale that would have been difficult independently.

Maybe SpaceX leaves the product unusually autonomous. All of that could happen.

I just think the independent position was more valuable than it looked. And unlike compute, independence is not something Cursor can easily buy back later.