Blog

The $1M Agent: Three Lessons From Building Linter Agent

May 2026

Linter Agent optimises data pipelines, and has so far transformed 100+ slow, expensive pipelines into faster, cheaper ones across 5+ enterprises. Saving over $1m in under 6 months. Whilst building this agent, 3 key areas have stood out:

1. What should the agent do?
2. How to build trust in our agents?
3. How do agents compound and self-improve over time?

Let's break these down:

What should the agent do?

Building agents has become much easier.

I can now prompt Claude Code to build a custom agent using an agent SDK, describe its responsibility, tools and data access in natural language, then give it examples and tests so it can run, fail and improve.

The bottleneck has become purpose — where can an agent fit into my company and what should it do?

Here are some perspectives:

1. Backlogged skilled work
   • Linter Agent went after code optimisations — this is an abundant space where years (/decades for pre-cloud stacks) of legacy code has accumulated and the bottleneck is squarely on skilled human labour.
   • Where are you accepting delays, bringing in consultants or paying overtime to remote workers?
2. Increase the search space — work where humans currently sample, audit, or ignore low-value cases because full review is too expensive
   • In large enterprises there are certain dollar values under which most approvals are automated because the cost of human verification is too high relative to the volume; this changes when you have a set of AI eyes!
     • For example, in procurement, collections, support, etc.
     • Alternately, think of internal teams that rotate around to do audits (e.g. cyber security swat teams).

How to build trust in our agents?

Linter Agent has generated over 50 PRs; what matters is getting these merged — this can be the tough part, from chasing SMEs down to iterating on tacit knowledge.

Here are some questions we should answer early on:

• Who signs off your work? Who are the "Oracles" or SMEs you turn to when unsure?
• What do they need to see to be able to quickly come to a conclusion on your agent's outcome? How can you make it easier/faster for the approver to get to a yes?

I've learnt that if reviewers need extra data to approve/reject, then that data is valuable missing context for your agent.

Do not only optimise the agent's output. Optimise the review path.

For Linter Agent's approvers, coding/data outputs are easier to verify, using compilation checks, tracking non-functional attributes (latencies) and SQL analysis over the final datasets (branch level data comparison to user defined precision).

A note on change management: Linter Agent mostly runs in the background. Some agents are more front-and-centre and change how people work day to day. In those cases, adoption has required a more personal human touch: helping teams understand what the agent is doing, where it fits, and how their role changes around it.

I am particularly interested in how others are building adoption in organisations with widespread legacy software. How are you using AI to productise what was previously a services-heavy change management motion?

How do agents compound and self-improve over time?

At work, we often value experience, as we've seen people get better at their responsibilities over time.

They learn the edge cases, the shortcuts, the exceptions, the preferences of reviewers, and the hidden constraints that never quite make it into documentation.

For agents to compound the same way, they have to absorb tacit knowledge from the SMEs around them. That sounds straightforward and isn't, for two reasons.

Tacit knowledge is, by definition, not in the trace.

Logging the agent's reasoning tells you what the agent considered. It doesn't tell you what an experienced reviewer would have noticed and the agent missed. The data you need is in the SME's head, and the only way to get it is to ask — at the right moment, with the right structure, in a UX they'll actually engage with. Free-text PR comments put the onus on the reviewer, whereas structured questions tied to the specific data/decision help the reviewer.

Experts can disagree, and the disagreement is the signal.

Two SREs will give you different opinions on the same Linter Agent PR. Both will sound right. If your feedback system treats this as noise to average over, you'll get an agent that's mediocre by consensus. The leverage is in surfacing the disagreement and asking the disambiguating question: what about this case made you call it differently from a similar one last month? The answer is a constraint — a context variable the agent didn't know about — and now it does.

What I want Linter Agent to compound on:

• the scope and complexity of an actionable optimisation increasing
• median end-to-end time falling
• fewer interventions between PR opened and merged

These are the visible outputs. The mechanism underneath them is the same mechanism that grows a junior engineer into a senior one: better intuitions about what matters in a given context, learned from being corrected by someone who already knows.

The custom UX is where this happens. It asks the right question, shows the right comparable cases, and captures not just the verdict but the context the verdict depended on. That's the flywheel.

The agents that compound are the ones whose reviewers are giving them apprenticeship, not approval.

What do smarter models mean for white-collar labour like me?

February 2026

An FDE's perspective.

I recently gave a talk at a Palantir all-hands for Forward Deployed AI Engineers — sharing some ideas below.

The purpose of an FDE doesn't change, but an FDE's leverage is growing significantly as techniques for collaborating with AI labour evolve, with emphasis on context management, orchestration and verification.

What isn't changing

The purpose of a forward deployed engineer:

1. finding and creating meaningful value
2. getting your use cases into production — only then thinking about scaling through product, relationships or brand

Finding meaningful value means finding the root cause, not solving the symptom. Nothing works better than showing an MVP on real data to SMEs and watching where it earns trust, where it breaks, and where it changes decisions. Iterate quickly and keep the feedback loop tight.

What's changing

Five years ago, the bottleneck was building fast enough to keep stakeholders engaged. This bottleneck is fast disappearing as AI agents get better.

The best FDEs who are compounding value today are leaning into AI, focusing on:

Context management
Writing down context to a fidelity where any person, or agent, can pick up from where you left off. Tactically, this means centralised knowledge bases (ontology, monorepos, …), easy to search (good indices) and evolving with human feedback (simple UXs).

Orchestration
Over time we've seen AI's remit expand from chatbots to agents and so on. Organisations are now running workflows and business processes with agents. Orchestration is defining the process graph (key steps and handoffs), escalation (how are errors and uncertainty handled), and observability (what are your agents doing under the hood).

Verification
As AI's remit grows, so does its output, which puts greater focus on verification and alignment. Encoding the checks your SME applies intuitively, and closing the loop so the system can self-correct rather than silently drift. Put differently: what's required to get sign-off?

Concluding thoughts

Right now, there's a lot of FOMO — new model releases, impressive demos, huge fundraising rounds.

Focus on the first principles. Your advantage as an FDE is proximity to reality: the customer's data, decisions, and bottlenecks. Remove the next bottleneck, get your agentic workflows into production, and let usage pull you up the abstraction ladder. That's the compounding loop.

Competition at Palantir

January 2026

Palantir's AI-FDE is the substrate on which Linter Agent is built.

But how was AI-FDE itself built?

It wasn't a single, top-down roadmap. As Shyam Sankar notes, it was the result of multiple internal teams working on the same problem. Internal competition isn't a bug — it's the mechanism that forces the best execution to the surface.

When internal competition works, the product thrives. Here is why:

Theories vs. Empirics
At Palantir, code is open source internally. Given the current state of AI coding agents, there are zero barriers to turning an idea into reality. Don't argue about the "right" way to build; let the empirics speak for themselves and let the users decide what sticks.

Beating Complacency
Products built on inherited monopolies often stagnate — look at Siri vs ChatGPT's trajectory. No internal competition leads to a "default" mindset. You have to earn your place in the stack every day.

Owning the Direction
Because there are no de-facto monopolies internally, you have the freedom to take a product in an independent direction. This is where judgement — or "taste" as we call it — matters:

• Which user group do you obsess over?
• How do you reach them?
• How do users drive product direction and vice-versa?

Usage is a good metric, but the real goal is finding the economic value downstream of that usage. What is the value function? (I'll talk more about this next time…)

Commoditisation is Inevitable
Competition means your best features will eventually commoditise. This forces you to think about how your product compounds.

If you rely on open source to build quickly, you have to find your unique value proposition — whether that's a user growth flywheel or capturing the fidelity of a user's preferences and decision-making process so deeply that shifting to a competitor is no longer worth the lift.

The best execution wins because it has to.

Palantir's AI-FDE is the substrate on which Linter Agent is built. Reach out if you're interested in how we're building the next generation of AI tools at Palantir.

The Forward Deployed Model

14 December 2025

The Forward Deployed model is the ultimate product incubator.

It's why tools like Linter Agent exist today.

The leverage isn't just the technology — it's the team structure.

Lean teams of 2–3 own the full vertical slice: discovery, building, go-to-market, and deployment.

Discovery
We embed with customers to learn about problems firsthand, separating symptoms from root causes.

Iteration
Build fast and fail early. Scale doesn't matter yet — trust and real user adoption do.

Validation
Test early wins across customers — do others actually care about this problem?

This is where product taste matters: deciding what stays a custom fix and what becomes a scalable AI capability.

Linter Agent wasn't a guess. It was the same question, heard in different forms, across many customers.

Reach out if you are interested in learning more about Linter Agent or the Forward Deployed model, more broadly.

The kicker: you're rarely the only team to spot a good problem. Next time, I'll talk about how Palantir encourages competition so only the best execution wins.