It's difficult to put the blame for that on the consumer, who has no visibility into manufacturing or logistics, and who has vanishingly-small options for not participating. Buying domestic goods is very difficult or impossible, and goods which are manufactured in more environmentally-safe ways are significantly more expensive (because the costs I mentioned earlier weren't externalized).

If a consumer is presented with two options, one that costs $X and has unknown environmental costs, and one that costs $2X and is marketed as being environmentally safe, the majority will choose the first. This is especially true as economic forces continue to squeeze average people.

Consumers absolutely participate in the problem, but the only process by which it could be corrected is regulation, and the only entity capable of that is the government. (Democracy being what it is, you can however place more blame at the feet of voters.)

Ardent is an agent running in a desktop (Electron) app built to help with knowledge work, designed for less-technical people outside engineering. Think Codex or Claude Cowork, but built around collaboration and customization.

I know, I know, it’s yet another agent harness! Ardent is a little different – it leans heavily on codegen to solve problems. Most agents are basically just a bag of tools and a while loop, but Ardent writes code to complete tasks, making it much faster and more token-efficient. [0]

Lots of companies are trying to build their own agent harness right now, because token budgets make software appear cheap, and it seems like a competitive advantage to own a custom agent.

The thing is, agents are deceptively complex. They aren’t light wrappers around the model anymore; the harness makes a big difference in how capable the agent is. They also come with lots of sticky problems: context management, sandboxing and permissions, authz/authn to remote services, etc.

Instead of building your own harness from scratch, you can customize Ardent using abilities: TypeScript libraries that can expose tools and prompts which can be used by the agent. They’re like agent skills, but closer to regular code libraries: type-safe, importable, and with well-defined permissions. Ardent can help you build abilities, but you can also create them by hand if you prefer.

Anyone can share abilities with everyone in their organization with a single click, and if Ardent notices that the user is doing repeatable work, it offers to transform the adhoc solution into a reusable ability. Say you prepare the same project update every Friday, pulling issues from Linear and docs from Google Drive. Ardent can turn that workflow into a reusable ability that you can share with everyone in your company.

Your company’s ability catalog is like a standard library. To solve a problem, Ardent searches for existing abilities, and then writes glue code to compose them. Because the code is ephemeral, it doesn’t need to be maintainable, which lets us use cheaper, less-capable open weight models like Kimi and GLM. [1]

Code executes on the user’s machine in a Deno sandbox with zero permissions by default. Abilities declare required permissions up front, and any code that exceeds the current scope gets terminated and prompts the user for approval.

Ardent can also connect to a bunch of tools which you’re already using, like Google, Linear, and so on. We support MCP servers, but in our experience, MCP is slow, token-expensive, and provides a pretty bad experience for both agents and users. [2]

Instead, Ardent connectors handle auth, but instead of using MCP, we generate client shims which call the service’s primary API. This is a much better fit for Ardent’s codegen approach, because the agent can read the client and treat it like any other library.

There’s a bunch of other interesting stuff in Ardent: memory, conversational recall, scheduled tasks, prompt suggestions, and so on. During our beta period, we’re selling inference at-cost, and we’re giving each organization some free credits to experiment.

Please take a look and tell us what you think! We’d love your feedback, whether you think what we’re doing is good, bad, or meh. I’m also happy to answer any questions that you might have.

---

[0] Cloudflare has taken to calling this “code mode”: https://blog.cloudflare.com/code-mode/

[1] In our benchmarks, Ardent consumed 63% fewer tokens than Opus running in Claude Cowork, with half the model requests.

[2] MCP servers rarely define input/output contracts, and it’s hard to write code that calls a function when you don’t know its arguments, or even its arity! Here's a good read on the subject: https://www.blacksmith.sh/blog/code-smith-code-mode

Comments URL: https://news.ycombinator.com/item?id=49550931

Points: 10

# Comments: 2

What really happened is that Stripe's products used to be simple. If you're only accepting credit cards and only serving the US market, the API surface is extremely simple. Once you start going multinational and accepting different types of payments it gets much more complex.

For example, OXXO gives users a barcode and lets them take it to a physical location and complete the purchase, so instead of a system like Visa which can confirm a transaction in a maximum of O(seconds), you also have to support methods where confirmations take O(days). Building custom API endpoints for each payment method isn't realistic, since there are hundreds worldwide, and merchants want a single integration point that can support anything from credit cards to coupon-based systems like OXXO.

TL;DR -- Stripe's APIs are definitely more complex now, but it's not because of poor design, it's because they simply have to be in order to serve the customers and markets the company is now reaching.

With all that said, I don't think we can extrapolate that their business wasn't doing well or that they couldn't have raised more money. Cloudflare probably just offered a good enough deal that it didn't make sense to try to grind it out.

What I really mean is that when M&A happens, it seems like a lot of people think the acquirer is the only one with any agency, and that's not true at all.

> 1. The producers and marketers (PMs/Sales). [...]

> 2. The leadership (CEO/VPs). [...]

I'm sorry, what? Product managers are producers and executive leadership are innovators, but engineers are just waste?

I have always been (and remain!) bearish on crypto but it absolutely was something that couldn't be ignored a few years ago. Even if you came to the conclusion that it was bunk, there was significant enough fervor that any technologist needed to reckon with their position on it.

For example, lots of engineers proclaimed very loudly that document databases would replace the RDBMs, or that GraphQL was the future of APIs. They were wrong, as it turned out, but only with the wisdom of hindsight.

The CEO made it seem like he himself didn't know how the math for the offer worked, and even when presented multiple opportunities to correct that impression, he made no attempt to convince anyone otherwise.

(To be clear, they're all drugs, and they should all be used responsibly if at all.)