Assem Chammah

The through-line

Across these posts the same argument keeps resurfacing: most of what gets sold as "AI transformation" is either mislabeled automation, a proof of concept that will never survive contact with production, or a billing structure designed to keep the client paying forever. The recurring move is to strip the hype back to mechanics, whether that means naming the token math behind a $100k bill, counting the RPA maintenance tax, or pointing out that a PE firm asking for an "AI agent" actually needs a deterministic script. Over the run of posts this hardens from diagnosis into a fairly consistent playbook: pick one workflow, deploy it to production immediately, match the tool to the task's error tolerance, and let the business team own the result rather than routing every change through engineering [7][9][14].

On matching the tool to the task

The clearest recurring principle is that agents are not automatically the right answer. On a payroll cost-cutting request: "AI agents hallucinate. For anything financial where you want 100% accuracy, and zero errors - AI is just not a good tool to use" [9]. The framework that follows splits work into automation ("Anything where 99% right is wrong"), agent ("Anything that takes a human 20 minutes of judgment per case"), and hybrid, where a "Script for the 99%" hands off "the 1% of edge cases" to an agent with human review [9]. The same instinct shows up when reviewing a consultancy's "agentic" build that was really "just built a bunch of automations + rules," which he calls "completely fine - if that's what the use case needs" until complexity breaks it [1]. RPA gets the harshest read: "70-75% of RPA total cost of ownership goes on building, fixing and maintaining them," because "Building the thing is easy. Keeping it current as reality drifts is what no company does" [3].

On cost efficiency

Model economics get treated as a lever anyone can pull. Cutting a client's AI bill "from $100k to $60k/mo Without losing any quality" came down to swapping models with comparable benchmarks at a fraction of the token price: "Opus 4.8 costs $5 per million input tokens, $25 per million output tokens... And Sonnet currently costs $2 per million input tokens, $10 per million output tokens" [2]. The conclusion is generalized past the one client: "Pretty much any organization can run this exercise and dramatically cut their AI bill" [2]. Ramp's spend data is read the same way, as evidence that budget size isn't the differentiator: "Median company spends $11.38 per employee per month" while "Top 1% spend $7,449," and that gap comes from buying "verticalized AI" instead of "one chat seat" [8].

On business teams owning AI, not engineering

A second theme is removing engineering as a bottleneck for iteration. Describing a client build: "the business team owns it completely. They don't need to go to engineering to change anything. They can tweak it, test new use cases, and iterate directly" [12]. This is generalized into a claim that forward-deployed engineers aren't even necessary anymore: "You DON'T need an FDE to implement AI," because the two components of an agent, "Harness" and "Prompt," can both be "prebuilt" so that "nobody can access things they shouldn't" while the business side operates freely [14]. The Nexus boilerplate work extends this logic to infrastructure itself: "Credentials never leave Nexus... Your business team builds the app. They never touch an API key" [4].

On how consultancies bill for AI

The critique of vendor incentives is pointed and specific. On per-change-request billing: "Every tweak to that agent becomes a change request... Charging $100k+ a month, with no end date on the invoice," which he calls "robbery" because "Build once is a fallacy" and "Nothing in a per-change contract rewards speed" [15]. Proof-of-concept culture gets the same treatment: "POCs create endless loops. You run one POC, get decent numbers, leadership wants another POC with more realistic data," and the fix is to "Pick one workflow" and "Deploy to production immediately," accepting that "it will make mistakes" [7].

Takeaways

• Before building an agent, classify the task by error tolerance: automation for "99% right is wrong" work, agents for judgment calls, hybrid with human review for the edge cases [9].
• Rerun model choice as a cost exercise: comparable benchmark performance at a lower per-token price can cut AI spend by 40% without losing quality [2].
• Treat RPA as a maintenance liability, not a one-time build, since 70-75% of its total cost is upkeep and roughly 45% of bots break weekly [3].
• Skip the proof-of-concept cycle. Choose one workflow with clear inputs and outputs, ideally customer-facing, and deploy straight to production [7].
• Push agent ownership to the business team by prebuilding the harness and prompt layer, removing the need for a forward-deployed engineer per client [14].
• Avoid per-change-request billing for AI systems since agents require continuous tweaking and that pricing model rewards slowness over ROI [15].