# Read the Job Post, Not the Pitch

By Wes Pomeroy. Published July 11, 2026. https://wespomeroy.com/writing/ai-job-posts-vs-vendor-pitches/

I don't read LinkedIn the way LinkedIn would like me to. I built a browser extension, [FeedHacker](https://chromewebstore.google.com/detail/feedhacker/kccajfoghkplakndamlohpepopdpelkb), that hides the junk in my feed - the machine-written filler, the bait, the rest of it. Then I built the other half: something that goes looking for the good posts and drops them into a queue in an app of my own. I go through that queue almost every day. It's where a lot of my learning comes from now, and it's how I find the others - people scattered across companies and countries who are working on the same problems I am.

Yesterday the queue handed me a job post.

[Muthu Chandra](https://www.linkedin.com/in/muthu-chandra/), a Chief AI Architect at [CitiusTech](https://www.linkedin.com/company/citiustech), is [hiring an AI engineer](https://www.linkedin.com/feed/update/urn:li:activity:7481154614403182592/) to build AI that does things instead of just answering questions. Not a chatbot. Software that takes a task, works out the steps, and carries them out inside a company's systems. I don't know him. I'm not an engineer, the job is in India, and I am obviously not applying.

I read it twice anyway, because of what it asked for.

## The Job, in Plain Terms

Set aside the specific tools it names. They'll be different next year and they don't matter here.

The post is looking for someone who can build AI that works through a job step by step and checks its own work. Someone who can plug it into the company's own information so it isn't guessing. Someone who can put hard rules around it, so it can't do certain things on its own, and build a way to test it - a set of tough example cases you run it against, over and over, so you can tell whether a change made it better or worse. And someone who can sit down with the people who actually do the work and turn what they know into how the AI behaves.

That's the ask. It reads like a shopping list. It isn't.

## Every Requirement Shows They Get It

Go back through what it actually asks for. Each item is proof that somebody there understands what this technology is and what it takes to run it safely.

It asks for guardrails and a way to evaluate reliability. Guardrails are hard limits on what the AI is allowed to do by itself. Evaluation is a standing set of tough cases you run it against, over and over, so you can see whether a change helped or hurt. You only ask for those two things if you already expect the AI to reach for something it shouldn't, and expect it to get things wrong sometimes, and you want to find that out yourself before a customer does. That's not pessimism. That's knowing the material you're working with.

It asks for this in regulated industries: healthcare, finance, insurance. In those places a wrong answer can mean a fine, a lawsuit, or a patient who acted on bad information. Someone has thought about what a bad outcome would cost the company, and built the job around preventing it.

It asks for the AI to be wired into the company's own tools and data, so it isn't guessing. Whoever wrote this knows the difference between a chatbot that tells you something wrong and an agent that does something wrong, inside a system other people depend on.

It asks for someone to work with the company's experts and turn what they know into how the AI behaves. That's someone who understands that the knowledge the AI needs isn't in the AI. It's in the people who do the work. Some of it can be written down and built in, and it should be. But the cases that decide whether this works are the ones nobody ever wrote down, and they keep coming. The experts don't hand over what they know and go home. They stay involved, and that involvement is what keeps the system improving instead of quietly getting worse.

The post never claims any of this. It doesn't have to. Asking for the right work is the proof.

## Someone Is Going to Sell You One of These

Sooner or later a vendor is going to pitch your company an AI agent - software that doesn't just answer questions, it goes and does the work, inside your systems. Probably this year. Probably more than one of them. And probably with a slide showing the headcount it replaces, or the hours it saves, or the money it frees up, or the growth it unlocks.

You are never going to know the technology better than the people building it. That isn't your job, and you don't need to. But you can learn to tell a thin pitch from a solid one, and you don't need to understand the software to do it. It comes out in how they talk about the work, in plain conversation, long before anyone shows you a diagram.

What it can do is the easy part. Every vendor has that answer, and most of them are roughly right about it. Ask them about the bad days instead. What goes wrong. How often. And what they're doing to keep it from reaching you when it does.

This technology gives you a likely answer, not a guaranteed one. Being wrong some of the time isn't a bug someone will patch out next quarter. It's part of what you're buying. Software that acts for you, in front of your customers, and is confidently wrong two percent of the time is not two percent of a problem. It's a small but genuine chance of a very specific, very expensive mess, every single time it runs.

So notice who brings up the limits first. If the person selling you this can't tell you what your operation looks like after it lands - which work changes, what your people are doing differently, what can go wrong and how they'll catch it - then one of a few things is true. They haven't worked it out. They plan to work it out on your budget. Or they'd rather you didn't ask. None of those are things you want to find out in month eight.

## What to Ask Before You Sign Anything

None of this is an argument against letting AI run on its own. It works. I build with this technology every day and I've watched it do things I wouldn't have believed three years ago.

But it works under conditions, and those conditions are the design.

Give it a narrow enough job that you can say what a wrong answer looks like. If you can't say what wrong means, you can't hand the work over. Check it, so you find out it's wrong before your customer does. Decide up front what it is never allowed to do by itself. And keep the people who know the work close to it, permanently, because they catch what the tests miss and they're the ones who teach it what to do instead.

Those aren't safety features bolted on at the end. They are the plan. How narrow you make the job decides how much risk you're taking on. How well you check it decides how much you can safely hand over. And the work you can't check, or can't afford to get wrong, is where your people stay. Everyone argues about what AI will do to jobs. It actually gets decided in choices like these, by the people making them, and most of the arguing never gets near that.

So when someone pitches you an agent, don't start with what it can do. Ask what it isn't allowed to do on its own. Ask how they'd know it went wrong, and how fast. Ask who looks at the hard cases, and where what they learn ends up. Ask what it costs to keep the thing working in year two, and who's doing that work.

If the answers are thin, what you're being shown is a demo.

That job post sold nothing and promised nothing. It just wrote down what the work costs, in public, while most of what crosses my screen is still about what it saves. That's the sound I've tuned my feed to find.