Fixed Point Consulting — Insights

Brilliant Orchestrator, Terrible Database

Fixed Point Consulting — Fri, 07 Aug 2026 00:00:00 GMT

We've watched more than one team build a brilliant orchestrator on top of a terrible database.

The agent worked. That was the problem. It read the stale field, trusted the duplicate record, took the side of whichever system it queried first when two of them disagreed about the same fact — and then executed on all of it, confidently, at scale. The model didn't fail. It faithfully amplified everything wrong underneath it.

Before AI, those data problems were survivable because humans quietly absorbed them. People knew which report to distrust and which field hadn't been updated since the migration. That reconciliation never got written down; it lived in heads. An agent doesn't have a head to live in. It reads what's there and believes it.

Which is why the first question in any agent engagement isn't "what should the agent do?" It's "what does the agent read — and is it true?" Establish the source of truth, resolve who wins when systems disagree, and decide what the agent does when the answer is missing rather than wrong. That work is unglamorous. It's also the entire difference between automation and automated error.

Ground truth before intelligence. The order isn't negotiable — intelligence pointed at a fiction just gets you to the wrong place faster.

The Babysitting Paradox

Fixed Point Consulting — Fri, 07 Aug 2026 00:00:00 GMT

"If I have to check everything the agent does, what's the point?"

That's the most honest objection in enterprise AI, and most teams answer it the wrong way: they check less as they get comfortable. Trust accumulates through runtime — it ran fine for a month, so loosen the leash.

Runtime is not how you earn autonomy. It's how you accumulate unexamined risk.

The paradox resolves at design time, not run time. You decide, before the agent touches anything real: where it stops, what it must confirm before acting, and what it may never do alone — no matter how long it has behaved. Those boundaries aren't restrictions on the system. They are the system. They're the difference between delegation and abdication.

Get them right and supervision changes shape. You're no longer babysitting every output; you're reviewing the specific moments the architecture routes to you — the ones you defined as needing a human. Nobody stands at the pool fence all day. That's what the fence is for.

An agent you have to watch constantly isn't autonomous, it's a very fast intern. An agent you never have to watch isn't trustworthy, it's unaudited. The real thing lives in between, and that space is drawn by boundaries you architect on purpose.

Boundaries are the feature. Everything else is a demo.

The Cloud Question

Fixed Point Consulting — Fri, 07 Aug 2026 00:00:00 GMT

A clinical research lead once asked us, only half joking, whether there was a cloud following her around collecting everything she did.

Fair question. The honest answer was yes — and the uncomfortable part wasn't the collecting. It was that nobody had architected what the system was allowed to do with what it saw.

That's the state of most AI rollouts in regulated environments right now. The model is fine. The governance around the model is vibes.

If you're putting agents anywhere near clinical or regulated data, three architecture moves do more for your validation story than any model upgrade:

Pin the model version. If behavior can silently change under you, you cannot claim a validated state. Upgrades become controlled changes, not surprises.
Make the agent propose, not decide. Drafts, flags, and recommendations that a qualified human commits. The signature stays where the accountability lives.
Keep a golden test set. A fixed batch of known inputs with known correct outputs, run against every change. It's the cheapest audit evidence you will ever produce.

None of this limits what AI can do for you. It's what lets you say yes to it in an environment where "the vendor updated something" is not an acceptable root cause.

The cloud is following everyone around now. Architect what it's allowed to do.

Trustworthy Autonomy Is an Architecture Problem

Fixed Point Consulting — Fri, 07 Aug 2026 00:00:00 GMT

Every few weeks a new model tops a benchmark and the demos get more impressive. Meanwhile, the share of enterprise agent pilots that ever reach production barely moves.

That gap is not a model problem. The intelligence is now the part you buy. What separates a demo from a system you can rely on is everything built around the agent — the ground truth it reads and the boundaries it operates inside. And what happens when it fails, because something always does. None of that ships with the license.

That's architecture. It's the work.

We named the firm for it. A fixed point is the reference everything else gets measured against. Before an agent earns autonomy, something has to hold still: one source of truth. One identity model. A hard definition of where the agent stops and a human signs. Establish those fixed points first, and autonomy stops being a leap of faith and becomes an engineering decision.

Fixed Point Consulting builds agentic systems for organizations that need them to be right, not just impressive — including regulated environments where "mostly correct" is a finding, not a feature.

Trustworthy autonomy is an architecture problem, not a model problem. That's our thesis. Everything we publish here is some version of proving it.

Debugging Power Automate Without Opening the Designer

Christa Campbell — Thu, 06 Aug 2026 00:00:00 GMT

I debugged Power Automate flows this week without opening the Power Automate designer once.

Claude Code, connected to the Power Automate MCP server.

The workflow: I describe the failure symptom. Claude pulls the flow definition, walks the run history, finds the failed action, reads the inputs and outputs on either side of it, and tells me what actually broke — not what the error message claims broke.

Anyone who has debugged a flow through the designer knows the ritual. Open the run. Expand the action. Expand the next action. Squint at a JSON blob in a box four lines tall. Repeat for forty actions. The designer is a fine authoring surface and a miserable debugging surface.

An agent with MCP access doesn't squint. It reads the run history as data, diffs the failing run against the last successful one, and comes back with the actual cause: a connector started returning a different schema last Tuesday, and here's the expression that stopped resolving.

Doing this for real rather than as a demo has taught me two things. The agent is only as good as its access — scope the connection to the environments you want it reading, because least privilege matters more with agents, not less. And it's fastest on exactly the failures humans are slowest at: schema drift, expression evaluation, pagination weirdness. The unglamorous 80% of what actually breaks.

Step back and notice what this is. A Claude agent debugging Microsoft's automation layer through an open protocol. Cross-platform agentic work isn't a slide anymore. It's just work now.

The platform you author in and the platform you operate from are decoupling. Architects should be watching that seam.

MCP Is the Badge System for Your New AI Workforce

Christa Campbell — Tue, 04 Aug 2026 00:00:00 GMT

If AI agents are the new workforce, MCP is the badge system that decides which buildings they can enter.

MCP stands for Model Context Protocol. It's the standard that lets an AI agent connect to your actual systems — CRM, finance, document libraries — without a custom integration built for every single pair. One standard plug instead of a hundred bespoke wires. Every major vendor now speaks it: Microsoft, Anthropic, OpenAI, Google, Salesforce.

On July 28 it got its biggest overhaul since launch. You don't need the engineering details. You need what they mean for you.

It now scales like normal infrastructure. The old version needed special handling to run at enterprise size. The new one runs on the same boring, reliable plumbing as everything else in your stack. Fewer exotic failure modes, lower cost to operate.

Security moved to where your IT team already lives. What agents can touch is now controlled through your identity provider — the same system that governs employee logins. Sign in once, IT decides which doors open. Your security team stops approving connections one at a time.

And there's a 12-month clock. Older versions are being phased out. If your organization has agents in production — and most now do, sometimes without leadership knowing — someone owns a migration plan. Worth asking who.

The pattern underneath: agent infrastructure just stopped being experimental and started being governed like everything else you run. That's not a slowdown. That's what technology does right before it becomes load-bearing.

A question worth bringing to your next ops review: which of our agents can reach which systems, and who decided?

Commander's Intent: The Best Prompting Advice I Know

Christa Campbell — Fri, 31 Jul 2026 00:00:00 GMT

My father was a career Army Colonel. The best prompting advice I know, I got from him decades before prompts existed.

It's called commander's intent. You don't script a mission step by step — the plan dies on first contact anyway. You state the outcome, the constraints, and why it matters. Then the people executing can make a thousand small decisions you never anticipated and still land where you needed them to.

That's how I work with AI. I don't write instructions like a recipe. I write intent: here's the outcome, here's what's off-limits, here's why it matters and who it's for. Then I let the model handle first contact — the edge cases I didn't predict — because it knows what it's aiming at.

Step-scripted prompts break the moment reality deviates from the script. Intent survives contact.

The Army figured out delegation long before the AI industry did: autonomy isn't the absence of direction. It's direction good enough to survive without you.

The Most Important Architecture Decision Was a Table

Christa Campbell — Thu, 30 Jul 2026 00:00:00 GMT

The most important architecture decision in my last agent project was a table.

Not the model. Not the orchestration. A table — because of a quiet crime almost every business system commits: it overwrites its own memory.

Think about how a standard record works. Status changes: old value gone. Owner reassigned: previous owner gone. Date pushed: original date gone. The system always knows where things are and never knows how they got there. We built a generation of software with amnesia and called it "current state."

For twenty years that was mostly fine, because the questions were mostly "where is it now."

Agents changed the questions. An agent that validates, routes, or predicts doesn't learn from current state — there's nothing to learn from a snapshot. It learns from history: what bounced and why, what got escalated, what the exceptions had in common. In one recent build, the change that made the agent possible wasn't AI at all. It was converting an overwritten status into its own table, where every state change became a permanent row — when, why, by whom, how long.

Rows, it turns out, are the difference between a system that has data and a system that has experience.

So there's an audit I now run on any system before an agent touches it: find the fields that overwrite. Every one of them is a question the organization already decided never to answer — and usually the exact question the agent will need answered.

A status field tells you where something is. Only history tells you why. And why is the whole job now.

Model choices are reversible. Data model choices compound.

Your Agent's Blast Radius Is What Happens Between Checkpoints

Christa Campbell — Tue, 28 Jul 2026 00:00:00 GMT

Everyone is posting about the Open Secure AI Alliance today. Thirty-plus companies, a lot of press. Fine. That is not the part worth reading.

The part worth reading is in Nvidia's own explanation of why the alliance exists.

When Hugging Face got hit, the closed models they reached for would not run the forensic analysis. The systems could not tell an attacker from a defender, so they declined. Hugging Face ended up self-hosting an open-weight model to review more than 17,000 agent actions, by Nvidia's account, and contain the incident.

Seventeen thousand actions.

Sit with that number. That is not a model misbehaving in a single turn. That is an agent operating long enough to become an archaeology project.

Open versus closed is the loud takeaway. It is also the least useful one if you actually ship agents inside a regulated enterprise. The useful one: your agent's blast radius is whatever it can do between human checkpoints. If that number is 17,000, you do not have an agent. You have an incident with a future timestamp.

I build these systems for regulated research administration, where a wrong write to the wrong record is a compliance event rather than an oops. Every consequential action routes through a named human with an approval role. Not because it is elegant. Because when someone asks what the system did on a Tuesday in March, there has to be an answer that does not require self-hosting a foreign model at 2am to reconstruct it.

Fewer autonomous steps than the demos promise. Considerably fewer bad Tuesdays.

The alliance will produce useful tooling eventually. Until then, go count how many actions your agents can take before a person sees one of them.

The Line at the Bottom of My Posts

Christa Campbell — Fri, 24 Jul 2026 00:00:00 GMT

People ask about the line at the bottom of my posts. Here's the honest workflow behind it.

Every post starts with a filter, not a prompt: can I stand in this as a builder? If I haven't architected it, shipped it, or personally broken it, it doesn't get written — no matter how well it would perform.

Then AI earns its keep. It scans the news faster than I can. It drafts faster than I can. And before anything goes out, it argues with me — I have it attack the post the way a skeptical reader would, and the weak claims die in private.

What it never does is decide. It doesn't pick the topic, the position, or the line I'm willing to defend in the comments. The judgment layer stays human, because that's the only part anyone is actually here for.

If AI could write this post alone, you'd have scrolled past it already.

So the line isn't a disclaimer. It's a division of labor.

Drafted with AI. Sharpened by me. The thinking is mine.

Interview the Person Who Says No

Christa Campbell — Thu, 23 Jul 2026 00:00:00 GMT

The most valuable knowledge in your organization is why things get rejected. Almost nobody writes it down.

I built a Copilot intake agent for a clinical research institute, and the obvious version of that project was automating the form — faster submissions, fewer clicks. But the expensive problem was never intake speed. It was what happens downstream, when a submission bounces: rework. Every bounce is days of delay and a loop through a queue that was already full.

So before building anything, I did two things most agent projects skip.

First, I interviewed the reviewer. The person who bounces submissions carries an entire rejection taxonomy in her head — criteria she applies in seconds, refined over years, documented nowhere. What makes you send something back? What do you check first? What's the mistake people make over and over? That conversation was the requirements document. Not what users say they want — what the expert refuses to accept.

Second, I mined the rework history. Every bounced submission is a labeled example of failure the organization already paid for. Patterns fall out fast.

Both went into the agent as a validation layer. It checks each submission the way the reviewer would — before it enters the pipeline, not after it's wasted a spot in the queue. Rejection knowledge moved from the end of the process to the front. The reviewer reviews exceptions instead of everything.

The pattern generalizes anywhere a queue meets a reviewer: contracts, claims, credentialing, code review. Interview the person who says no. Their rejections are the spec.

The FDA Made Five Decisions Before It Trusted Agents

Christa Campbell — Tue, 21 Jul 2026 00:00:00 GMT

The most cautious regulator in the country put AI agents inside its own review process. If you've been telling your board that agentic AI is "too risky for a regulated environment," that argument just expired.

Last December the FDA gave its staff agentic AI — not a chatbot, but systems that plan and execute multi-step work across pre-market reviews, post-market surveillance, inspections, and compliance. The agency that decides whether your drug ships now runs agents on the reviews themselves.

Most people read that as "even the FDA is doing it." That's the wrong takeaway. The lesson isn't that they did it. It's how.

Look at the choices. The agents run in a locked-down GovCloud environment. The models don't train on staff inputs or on anything industry submits. Human oversight is built into the workflows. Use is optional, not mandated. And the work is scoped to specific, bounded tasks — not "go run the agency."

None of that is about the model. All of it is architecture. The FDA didn't ask whether the AI was smart enough. It decided where the data lived, what the agents could touch, who stayed in the loop, what stayed optional, and how narrow the job was. Then it turned the thing on.

That's the whole playbook for regulated work, and the most conservative shop in the industry just published it for free.

So the real question on your next agentic project isn't "is the model good enough." It's "have we made the same five decisions the FDA made before they trusted it." If you can't answer those, the model was never the problem.

The Failure Catalog

Christa Campbell — Fri, 17 Jul 2026 00:00:00 GMT

I keep a failure catalog. It's the highest-leverage document I own.

One running file. Every time a system breaks — mine, a client's, one I only read the postmortem for — it gets a line: what broke, what everyone believed right up until it broke, and what would have caught it earlier.

For years that file just made me harder to surprise. Then AI gave it a second job.

Now, before I design anything new, I hand the catalog to the model along with the proposed architecture and one instruction: tell me which of these failures this design is about to repeat. Pattern-matching across years of wreckage, in about a minute. It's wrong sometimes. It's uncomfortably right often enough that I've stopped skipping the step.

Experience isn't the years. It's the catalog. Most people live through the failures and keep nothing. Write them down, and even the machine gets smarter with you.

The Senior Move Is Scoping Down

Christa Campbell — Thu, 16 Jul 2026 00:00:00 GMT

When someone hands me a process to automate, the first thing I do isn't figure out how to build it. It's figure out how much of it I can ignore.

That sounds backwards. Most people scope a project by cataloging everything it has to handle — every case, every exception, every "but sometimes." The list gets long, the timeline gets long with it, and the whole thing collapses under its own completeness.

Here's what years of this have taught me. Almost every real process follows a power law. A handful of case types drive the overwhelming majority of the volume, and a long tail of edge cases feels important but barely moves the needle. The instinct is to treat them all as equal. They are not.

So before I design anything, I map the volume. Which cases actually happen, and how often. Nine times out of ten, a small set covers most of the work, and the rest is noise dressed up as requirements.

Then I build for the vital few and route the tail to a human. You cover the bulk of the real work with a fraction of the effort — and you ship while everyone else is still arguing about edge cases that happen twice a year.

This is also how you hit a deadline everyone called impossible. Not by working faster. By refusing to build what doesn't matter, and by changing the scoreboard from "how many features did we ship" to "how much of the actual volume do we cover."

The analysis is the easy part. The hard part is having the nerve to tell a room full of stakeholders you're deliberately not building most of what they asked for — and being right.

That's the value. Anyone can scope a project up. The senior move is scoping it down, on purpose, and standing behind it.

The Technology Is the Era. The Judgment Is the Career.

Christa Campbell — Tue, 14 Jul 2026 00:00:00 GMT

I've been automating the same kind of work for 25 years. The technology has changed three times. The hard part hasn't changed once.

Era one: SharePoint workflows. Documents routed for approval, forms replacing paper. Era two: the Power Platform - flows, structured data, apps replacing the spreadsheet everyone secretly ran the department on. Era three: agents that read the submission, apply the rules, and decide what happens next.

Every era arrived with the same promise: this time the tool is smart enough that you won't have to understand the process. Every era, that promise was wrong. The projects that believed it failed the same way across all three generations - and I know the pattern because those are the projects I get called in to salvage.

They automated the documented process instead of the real one. The real process lives in behavior: the workaround everyone uses, the checklist in the reviewer's head, the side spreadsheet that exists because the official system doesn't answer the actual question. Build from the binder and you automate fiction. Faster fiction, now with AI.

And they built the maximum solution instead of the right one. Some processes need an agent. Some need a flow. Some need one new field and one changed habit, and no software at all. Knowing the difference is worth more than any of the tools.

That's the part that compounds. The platforms, I've rented and replaced three times. The discipline - find the real process, size the build to it - has appreciated for 25 years.

The technology is the era. The judgment is the career.

Hire the FDE. Then Ask Who Owns the Wreckage.

Christa Campbell — Tue, 14 Jul 2026 00:00:00 GMT

Last week, four vendors committed $9 billion to embedded engineers. Here's what the money can't buy.

The hottest hire in AI right now is the Forward Deployed Engineer. Embed an engineer with the customer, ship fast, make it work in their environment. It's a real role, and the good ones are worth every dollar.

But I keep watching orgs hire an FDE and believe they've covered their architecture problem. They haven't. They've covered a different one.

An FDE optimizes for make it work here, now. That's the job — proximity, speed, the demo running in the customer's actual systems by Friday. Tactical, and valuable.

An architect optimizes for make it hold everywhere, later. Different question entirely. What happens at ten times the volume. What breaks when two agents collide. Which integration nobody scoped surfaces in month four. Where the human has to stay in the loop, and where they can't.

The gap between those two jobs isn't talent. It's time. An architect has stood next to enough systems as they hit production and buckled to carry a catalog of how things fail. You don't get that from being smart. You get it from being there for the wreckage — years of it — and designing against the next one.

And here's the part that costs the most: the FDE ships and rotates to the next account. The architect owns the consequences across time. The person who built it fast is long gone by the time the thing built fast comes due.

This isn't an argument against FDEs. It's an argument about the org chart. Most companies have a slot for the person who ships and no slot for the person accountable for the system holding — the identity model, the governance boundary, the failure catalog. Hire the FDE. Then look at your org chart and ask who owns the wreckage.

The Shape of AI Adoption

Christa Campbell — Thu, 09 Jul 2026 00:00:00 GMT

Everyone is talking about AI adoption. Almost nobody is talking about the shape of it.

The shape is a pyramid, and it is much steeper than the hype suggests.

The base is enormous. Most AI usage is the commodity layer: explanations, first drafts, summaries, guidance. Anthropic's Economic Index data shows exactly this - explanations and documents dominate what people actually produce. Also the easiest layer to replicate, because everyone is doing it.

The middle is real workers on real tasks. Roughly half of jobs have now had a quarter or more of their tasks touched by AI. That is observed usage, not a projection. But look closer and it is still mostly one task at a time, in a chat window, with a human gluing the steps together.

The top is orchestration. Systems connected to systems. AI that reads the meeting transcript, cross-references the email thread, queries the live database, proposes the schema change, and generates the deliverable - inside one governed loop, with a human accountable for the architecture. No survey measures this tier directly. It is too thin to survey.

Here is what should get your attention. The research on experienced users shows they do not just work faster. They attempt higher-value tasks and succeed more often. The gap between the tiers is not narrowing. It is compounding.

The adoption story everyone tells is about the base of the pyramid.

The economic story is about the top.

That governed loop at the top is not hypothetical. I ran it this morning: transcript in, email cross-referenced, live database queried, schema change proposed, deliverable out. The agentic layer is new; the architecture discipline underneath it is twenty-five years deep.

Trustworthy autonomy is an architecture problem, not a model problem.

Two Rooms, One True Thing

Christa Campbell — Fri, 03 Jul 2026 00:00:00 GMT

Half my job is saying the same true thing to two very different rooms.

The architects want to know how it works — the mechanism, the constraints, where it breaks. The executives want to know what it changes — the outcome, the risk, the number. Same idea. Completely different proof.

So I write it once, in plain terms, then have AI render it twice. "Give me the version a skeptical engineer needs to hear. Now give me the version a CFO needs to hear." Two minutes, not two hours.

What AI can't do is the part that matters: know what each room actually cares about. That's still on me. But once I know it, I stop rewriting the same point from scratch five times a week.

The skill is the translation. AI just does the typing.

Steal it the next time one message has to land with two audiences.

The Real Requirements Are in the Shadow Spreadsheet

Christa Campbell — Thu, 02 Jul 2026 00:00:00 GMT

The real requirements are never in the requirements doc. They're in the spreadsheet someone built because the official system doesn't work.

Every organization runs two processes at once. There's the documented one — in the SOP, the one people describe in meetings. And there's the actual one — the workarounds, the shadow spreadsheets, the "oh, we don't really use that field," the steps everyone quietly skips.

The gap between those two is where the truth lives. And it's the part requirements interviews almost always miss, because people describe the process they're supposed to follow, not the one they actually do.

This is where AI earns its place in discovery. Point it at the messy evidence of how work really happens — the tickets, the exports, the email threads, the tools people built for themselves — and it can synthesize the actual workflow out of the noise. Not what they say they do. What the evidence shows they do.

I've watched a single shadow spreadsheet rewrite an entire set of requirements, because it revealed the real bottleneck nobody mentioned in a single interview.

Build for the documented process and you ship something technically correct that no one uses. Build for the actual one and you ship something that fits how people already work.

Stop asking people to describe their process. Go find the evidence of it.

The Fix Isn't a Platform. It's an Inventory.

Christa Campbell — Tue, 30 Jun 2026 00:00:00 GMT

More than 80% of the Fortune 500 are already running AI agents. That's from Microsoft's own Cyber Pulse research. Most were built with low-code and no-code tools, by people who don't sit in IT, and nobody drew a map.

That's not adoption. That's sprawl.

Here's how it happens. Finance spins up a copilot to chase invoices. Sales builds a bot to draft follow-ups. Ops wires an agent into a system of record over a weekend. Every one of them solves a real problem. None of them know the others exist.

I've walked into orgs that couldn't tell me how many agents they were running. Not wouldn't. Couldn't. Those agents held access to data, could trigger actions, and answered to no one in particular.

We spent fifteen years learning this with identity. Accounts multiplied faster than anyone governed them, and the cleanup was brutal. Agents repeat the pattern, except they don't just hold access. They act, at machine speed.

The fix isn't a platform purchase. It's an inventory.

And it costs nothing to start. One row per agent. For each, name four things: who owns it, what it's allowed to touch, what it's allowed to do, and who can shut it off. The first row you can't fill in is the risk you didn't know you had.

Most orgs are still counting agents like trophies. The ones who pull ahead can name every one and say who's accountable for it.

You can't govern what you can't see. Right now, most can't see.

Ask the Machine to Disagree With You

Christa Campbell — Fri, 26 Jun 2026 00:00:00 GMT

Here's a habit that's saved me from more bad calls than anything else I do with AI.

Before a decision I care about, I don't ask AI to help me make my case. I ask it to tear my case apart. "Here's what I'm planning and why. Argue the other side. Find the holes."

It's ruthless in a way people in the room won't be — nobody's worried about my feelings or their standing. The weak spot in my logic shows up in seconds, while I still have time to fix it instead of getting caught on it live.

Then I walk in already knowing my plan's worst objection, and usually I've got an answer ready for it.

AI didn't make me more confident. It made me harder to surprise.

Try it before your next big meeting. Ask the machine to disagree with you.

Agentic Is a Capability, Not a Default

Christa Campbell — Thu, 25 Jun 2026 00:00:00 GMT

The most expensive agent is the one you didn't need to build.

A pattern I keep seeing across the industry — and I've been guilty of it myself: someone spends days building an agent for a task a good low-code UI would have handled in an afternoon.

A structured intake form. A route. A record created. No judgment, no ambiguity, no reasoning required. And still the instinct is to reach for the most powerful tool in the kit instead of the right one.

You can build almost anything as an agent. That's the trap. The question was never "can this be an agent." It's "should it be."

That distinction is the whole job. A deterministic UI flow runs essentially for free and fails in ways you can predict and debug. An agent makes multiple LLM calls every time it runs, so it carries a real cost on every execution and a probabilistic failure surface to match. None of that is a knock on agents — it's the reason you spend them where they earn it.

So before I architect anything as an agent, I ask one thing: is a real decision being made here, or are steps just being executed? If the input is structured and the steps are fixed, you don't need an agent. You need a form.

Done right, that discipline is what makes agentic investment pay off. Every agent you build is one that needed to exist. Reserve the capability for the problems that earn it, and the ROI takes care of itself.

Agentic is a capability. It is not a default. The hard part isn't knowing how to build agents — everyone's learning that part. It's knowing when not to.

Agents Don't Slot Into Your Org Chart. They Redraw It.

Christa Campbell — Tue, 23 Jun 2026 00:00:00 GMT

In a recent survey, 54% of executives said adopting AI is tearing their company apart. They've deployed the agents. They're spending millions. And it's making the organization worse, not better.

Here's what I think is actually happening. They bolted agents onto an org chart built for people, and the chart can't hold them.

Your structure assumes a person sits at the start of every workflow. Junior staff do the work, seniors review it, managers coordinate. Agents break it, because the agent now sits where the junior used to.

Flip the sentence and you see the whole shift. The old chart was: junior does, senior reviews. The new one is: agent does, human supervises. That small reordering moves the entry point of every workflow from a person to software, pushes humans up into oversight instead of down into production, and quietly removes the bottom rung of the ladder.

Which raises the real question: if agents do the entry-level work, where does the next generation of seniors come from? The pyramid produced experience as a byproduct. Now you have to produce it on purpose — by moving juniors into the oversight seat early, where they build judgment correcting agents instead of grinding rote work. The pipeline doesn't vanish. It moves up, if you design it to.

None of this is a prediction for me. I've drawn this chart. When you build a multi-agent system, you're designing an org — agents that execute, an orchestrator that coordinates, and humans who supervise and catch what they get wrong. The roles change first, not last.

Before you scale an agent, don't ask which tasks it can take. Ask who supervises it, and what your chart looks like once it does.

Agents don't slot into your org chart. They redraw it. The companies that thrive will be the ones holding the pen.

The Prompt Is the Easy Part. The Context Is the Job.

Christa Campbell — Fri, 19 Jun 2026 00:00:00 GMT

Stop trying to write the perfect prompt. You're optimizing the wrong thing.

Every other post in your feed is still teaching prompt tricks: magic phrases, the perfect opening line, "act as a world-class expert." That era is mostly over, and most people haven't noticed.

The quality of what you get back almost never comes down to how cleverly you phrased the request. It comes down to how much the model actually knew before you asked.

Think about it this way. If you handed a new hire a one-sentence request with zero background — no examples, no constraints, no idea what good looks like — and they turned in something mediocre, you wouldn't blame their wording. You'd realize you set them up to fail.

That's what most people do to AI every day. Then they go hunting for a better prompt.

The shift that matters isn't prompt engineering. It's context engineering: feeding the model the same inputs an expert would need to do the job. The real example. The actual constraints. The standard you're holding it to. What you've already tried.

Get the context right and a blunt, ugly prompt outperforms a beautifully crafted one running on thin air.

The prompt is the easy part. The context is the job.

Arrive Ready: Walk In With a Wrong Answer on Purpose

Christa Campbell — Thu, 18 Jun 2026 00:00:00 GMT

I don't walk into discovery asking "what do you need?" anymore. I walk in with a wrong answer on purpose.

Here's what I learned the slow way. Blank-slate discovery feels thorough and is actually the least efficient way to find out what someone needs. You sit in a room, ask open-ended questions, and get vague answers — because people are genuinely bad at describing what they want in the abstract.

But they are instantly, ruthlessly good at "no, not that."

So I flipped it. Before the first conversation, I use AI to build a hypothesis — a strawman of what I think they need, pulled together from their public materials, their industry, and systems I've seen solve the same problem. It's deliberately a first draft. Half of it is probably wrong.

That's the point. A wrong answer in the room gives people something to push against, and the corrections come fast and specific. "No, that step happens before this one." "We'd never approve it that way." In twenty minutes I learn what blank-slate discovery wouldn't surface in three meetings.

Discovery stops being extraction and becomes validation.

AI didn't make me faster at writing requirements. It made me able to arrive ready — with a point of view instead of a blank page.

That's the whole shift.

Copilot Studio Skills Ship With a Governance Problem

Christa Campbell — Tue, 16 Jun 2026 00:00:00 GMT

Microsoft is quietly replacing the topic model in Copilot Studio with skills — markdown playbooks an agent discovers and follows at runtime. Everyone's talking about the authoring change. Almost nobody is talking about the governance problem it ships with.

Here's the mechanic that matters: a skill activates when its description matches user intent. The description is a retrieval query. Which means two skills with overlapping descriptions aren't redundant documentation — they're nondeterministic routing. The agent picks one. You don't control which.

And the first skills every org will write are the unglamorous ones: which status field is source of truth, how the SLA actually gets calculated, what each pipeline stage means. Tribal knowledge that today lives in five agents' instructions, drifting independently. The moment it becomes discoverable, it becomes collidable.

The good news: business skills land as Dataverse records (preview today). User-owned, RBAC-shared, solution-aware. So the fix is boring and already exists — a registry. A model-driven app over the skills table, with similarity flagging and a review gate before anything goes org-visible.

Here's the part I like: the librarian doesn't have to be a person. The same MCP server that serves skills to agents can serve them to a governance agent — one that inventories every skill, flags semantic overlap, and proposes consolidation for a human to approve. Agents keeping the agents' knowledge clean. The platform governing itself.

Topic sprawl was visible — open the canvas, count the nodes. Skill sprawl is invisible until two playbooks disagree mid-conversation.

Trustworthy autonomy is an architecture problem, not a model problem. This is that, at the most unglamorous layer.

Five Things I Stopped Doing With AI

Christa Campbell — Fri, 12 Jun 2026 00:00:00 GMT

My biggest jumps in AI output didn't come from new tricks. They came from things I stopped doing.

Everyone's chasing the next prompt hack. The real gains were subtractive. Five things I stopped doing:

Stopped writing wall-of-text prompts. A clear role and one good example beats a page of instructions almost every time. The model doesn't need more words. It needs better signal.
Stopped trusting confident answers. The polished, certain-sounding response is the one most likely to hide a bad assumption. Now I ask what it's unsure about before anything else.
Stopped trying to one-shot complex work. The good stuff comes from building in passes — draft, interrogate, refine — not from expecting brilliance on the first reply.
Stopped using it as a search engine. Its real value isn't retrieving answers I could Google. It's pressure-testing my own thinking before I commit to it.
Stopped reaching for AI when a simple tool would do. Not everything needs a model. Sometimes the right answer is a spreadsheet, a form, or three lines of code, and knowing the difference is the actual skill.

The pattern across all five: better output came from restraint, not firepower.

Most people are trying to do more with AI. The leverage is in doing less, deliberately.

Long-Running Autonomy Isn't a Duration Problem

Christa Campbell — Thu, 11 Jun 2026 00:00:00 GMT

JPMorgan just said it's deploying AI agents that run for one to two hours with no human in the loop. Eventually, their analytics chief says, agents will run coherently for days, then weeks. The read is that the tech is finally close to clearing the governance hurdles that held it back.

Building this kind of system is what I do, so here's the part of the story I'd want a leadership team to actually hear.

Long-running autonomy sounds like a duration problem. It isn't. The longer an agent runs unsupervised, the more a small early mistake compounds — a wrong assumption in minute three becomes a wrong deliverable in hour two. Runtime doesn't reduce that risk. It multiplies it.

"Intellectual coherence" — their phrase, a good one — isn't correctness. An agent can be perfectly coherent and consistently wrong. Coherence is what makes the wrong answer convincing.

So when a team wants its agents running longer, I don't start with the model. I start with three questions. Where does the agent check itself against ground truth? Where does it stop and confirm? What is it structurally not allowed to do alone? Answer those and you've earned the runtime. Skip them and you're just scaling your blast radius.

And here's what makes it real for everyone who isn't JPMorgan: they can spend their way to the answer on a near-$20 billion tech budget. Most companies can't. They get there by being deliberate — knowing which questions to ask before the pilot, not after the walk-back.

If you're early in this, start there. Not with how long it can run. With what it's allowed to do when no one's looking.

The Moat Was Never the Model

Christa Campbell — Tue, 09 Jun 2026 00:00:00 GMT

Walmart paid the executive building its AI more than it paid its CEO last year. Its latest proxy filing put Daniel Danker at $44.1M and CEO Doug McMillon at $29.2M. That gap got passed around as a curiosity. I read it as a tell.

And it's working. On its Q1 call, Walmart said shoppers using its AI agent spend about 35% more per order, and units bought through it more than quadrupled in a single quarter. Dollars, not engagement metrics.

I build the same shape Walmart is building. Just not with five thousand engineers.

Here's the shape. Walmart consolidated dozens of disconnected bots and pilots into four agents organized by who they serve — customers, associates, suppliers, developers. Then it put an orchestration layer underneath, standardized on MCP, so the agents share context instead of each guessing alone.

Scaled down, that's my work: agents scoped by who's asking, an orchestration layer underneath, wired into the system of record. Same architecture. Orders of magnitude less budget.

The moat was never the model — everyone rents the same models. The moat is the structure: who the agents serve, how they hand off, what they share. That doesn't require Walmart's checkbook. It requires deciding the shape before you start collecting tools.

The move, if you want it, costs nothing. Draw four boxes, one per audience your org serves. Drop every chatbot, copilot, and stalled pilot into a box. You'll see your duplication and your empty front doors in about ninety seconds.

Most orgs are still accumulating agents. The ones who pull ahead drew the boxes first. Walmart just did it with more zeros.

The Most Valuable Agent in Clinical Research Doesn't Decide Anything

Christa Campbell — Thu, 04 Jun 2026 00:00:00 GMT

Most of the agentic AI conversation in clinical research is aimed at the wrong target.

Can it run the study? Can it replace the monitor? Can it make the call?

Wrong questions. And chasing them is exactly why the pilots stall.

Here's where agentic AI actually earns its keep in a trial right now — and it's almost insultingly unglamorous.

Reconciliation. The tireless, mind-numbing cross-checking that humans do badly precisely because it's mind-numbing.

Is every required document in the TMF, current version, signed, for every site? Is there a 1572 that quietly expired at site 23? A CV past its refresh? A consent version one revision behind in one place? Does the randomization system agree with the EDC agree with the drug accountability log?

None of that takes judgment. All of it takes patience no human reliably has at 5pm on the fortieth site file.

And here's why it's worth a fortune: those mismatches are exactly what an audit finds. What an inspector opens with. The boring discrepancy you missed is the finding that derails the visit.

So the most valuable agent in clinical research isn't the one that decides anything. It's the one that notices the missing signature before the inspector does.

It's also the safest place to start. The human still owns every decision. The agent surfaces the discrepancy; a person acts on it. No autonomy to validate, no accountability gap to explain — just a tireless second set of eyes on the work nobody wants to do twice.

Stop trying to turn the agent into the scientist.

Turn it into the most patient coordinator's assistant you've ever had. That's the version that ships this year.

Novo Nordisk's AI Bet Is an Infrastructure Story

Christa Campbell — Thu, 28 May 2026 00:00:00 GMT

Novo Nordisk's OpenAI partnership got a week of headlines back in April and then the cycle moved on. I'm still thinking about it — because the part that's actually hard was never the part anyone reported.

It's being read as a model story. It's an infrastructure story, and the hard part isn't OpenAI.

I've spent years building systems inside regulated clinical research environments. The part that's hard about a Novo Nordisk-scale rollout has very little to do with which AI is doing the work. It has everything to do with the layer underneath.

Start with the data. Clinical trial data is among the messiest data anywhere — pulled from dozens of sites, written under different protocols, captured in different versions of the same case report form, vocabulary inconsistent across studies that started two years apart. The "data ready" stage most AI projects assume already exists is something pharma companies pay vendors millions of dollars to maintain. It's still not really there.

Then layer GxP on top. In a regulated environment, an AI recommendation isn't usable unless it's traceable and auditable end to end. A prompt change is a controlled document. The output gets reviewed against the protocol. Any system in the workflow has to be qualified before anything it produces can affect a patient or a submission. That's the work the announcement isn't talking about, and it's the work that has to happen before any model output is considered usable.

Underneath all of that is the integration layer. CTMS, EDC, eTMF, LIMS, ERP — the systems Novo already runs were never designed to share data with anything, let alone with an autonomous AI orchestrating across them. Building that integration is the slower, more expensive part of this rollout by a wide margin.

None of this is a reason it won't work. Novo Nordisk is well-resourced and serious. But the timeline is ambitious. Twelve months in pharma is roughly one validation cycle if everything goes well, and rollouts of this scope rarely run without something going sideways. The rollout will expose how much of the work is infrastructure, not intelligence.

What I'd watch for: who they hire. The model decision is the easy one. The orchestration team is the project. The people they staff for this will tell you whether they understand that.

How Would You Know If It Was Wrong 5% of the Time?

Christa Campbell — Tue, 26 May 2026 00:00:00 GMT

Two weeks ago I wrote about the failure modes that hide when agents move from demo to production. Top of the list: the one where the agent quietly produces something plausible instead of saying "I don't know."

Datadog just put a number on it. One in twenty requests in production AI systems fails silently — the output looks right, the system keeps running, nothing trips an alarm. By engineering standards, a 5% silent failure rate is astronomical.

The number sounds smaller than it is. If your agent runs a thousand decisions a day, fifty of those are wrong in ways you can't see from looking at the output. The errors don't show up in logs because nothing failed. They show up downstream, days or weeks later, when somebody notices a number that doesn't add up or a customer complaint that traces back to a recommendation you can't explain.

The catastrophic version is in regulated industries. A 5% silent failure rate inside a clinical trial workflow is regulatory exposure, not a quality issue. The same rate in financial reconciliation is an audit finding. In environments where someone has to sign off on the work, the AI output isn't usable at all until the eval layer can catch those failures before they propagate.

Most teams haven't built it. Datadog's broader finding: fewer than 40% of production agents have automated evals running on every prompt change. The 5% is being discovered by customers, not by the team running the system.

What every ROI deck skips: the eval and observability layer isn't optional. If your agent is in production without it, you don't have a production system. You have an unsupervised intern with API access, and you'll find out what they got wrong from somebody downstream.

If you're running anything in production right now, pick one agent and ask the team how they'd know if it was wrong 5% of the time. If the answer is some version of "we'd hear about it," you have your next project.

A Skill Works When Nobody's There to Catch It

Christa Campbell — Thu, 21 May 2026 00:00:00 GMT

A skill works when nobody's there to catch it.

Most don't get tested that way. They get tested by their builder, on a curated set of examples, in the same week the skill got built. The whole time, the builder is doing half the skill's invisible job — filtering edge cases, catching weird outputs, quietly fixing things that don't look right before anybody downstream sees them.

The day the skill gets handed off, all of that disappears.

The right test isn't "does it produce the right answer when I run it?" It's "does it produce the right answer when somebody else runs it, on data I haven't seen, with nobody around to catch what slips?"

Most skills fail that test, and the failures look very similar.

Inputs come in missing or contradictory, and instead of flagging it, the skill produces something plausible. The number of skills I've watched silently invent data — because nobody told them refusing was allowed — is the most common failure mode I've seen.

Even when the data is fine, the output is often the wrong shape. If someone's using the output to approve a contract, it has to surface what drives approval, in the order it gets checked. If someone's using it to write a report, the output is structured around the report's sections. Summaries are not decisions, and skills that produce them make people feel busy without actually moving the work forward.

And even when the inputs are clean and the output is right, the skill often only works in its builder's hands. You hand it off and it falls over. What you built was a clever prompt, not a portable skill. A skill that requires its author to operate hasn't finished being designed.

Most skills fail at least one of these. That's fine, as long as it's caught now. Failing them quietly in production, with three teams downstream taking the output as truth, is a much more expensive kind of fine.

What gets skills shipped isn't passing the demo. It's surviving without you in the room.

Automate the Boring One First

Christa Campbell — Mon, 18 May 2026 00:00:00 GMT

The first workflow most teams try to automate is the one they shouldn't.

It's almost always the visible one. The strategy memo. The client recap. Whatever executive summary somebody senior wants off their plate. Creative, judgment-heavy work where being slightly wrong is the kind of mistake people remember. Not the right place to start.

The workflow that actually wants to be automated has a different shape. It happens constantly. The work is consistent enough week to week that you'd describe it the same way each time. And the person doing it can walk me through it in about fifteen minutes — without reaching for old emails to remember last week's example.

If those things aren't true, you're not ready to automate it. You're ready to interview the person who does it and write down what they actually do. That's the prerequisite. Most teams skip it.

The other thing nobody warns you about: error cost. Not theoretically — specifically. A weekly status report being a little off is recoverable. A client invoice being off is not. Map the failure modes before you build, not after.

The candidates that pass all of this tend to be boring. They won't appear in a board deck. Some specific person on your team spends three or four hours a week on the work and quietly resents the time. Six months after it's gone, nobody on the team will remember what it used to feel like to do by hand.

That's the right first one. The fancy stuff comes later, and by then you'll know what you're doing.

Your Demo Worked Because Nothing Was at Stake

Christa Campbell — Fri, 15 May 2026 00:00:00 GMT

Your demo worked because nothing was actually at stake.

The pilot looked great. Two months later it's quietly making bad decisions, your team has lost trust in it, and someone is asking why you spent six figures on something that mostly hallucinates.

Here are the five things that break first when an AI agent moves from demo to real work.

It makes things up — and doesn't flag it. When the agent hits a question it can't answer, it doesn't say "I don't know." It fills in a plausible guess and moves on. The wrong number lands in a report. The report lands in a meeting. By the time anyone notices, three weeks of decisions are stacked on top of it.

It gets sloppy the longer it works. The first ten things you ask it go great. Around the fortieth, it starts mixing up clients, confusing this week's project with last week's, picking the wrong vendor when you say "that vendor again." It's not malfunctioning. It just wasn't built to keep its place.

It pulls from the wrong place. An agent usually has to talk to five or six systems — CRM, file storage, project tools, email. When it picks the wrong one, or the right one with the wrong question, it produces a confidently wrong answer. Most agents have no way to catch this themselves.

It was tested on data that doesn't exist. The team that built it ran tests on clean, well-behaved data. Real data has missing fields, weird formatting, names spelled three different ways, integrations that time out at 4pm on a Friday. "100% accuracy" in testing means almost nothing the moment the agent meets your actual environment.

Nobody's watching when it breaks. The agent is making decisions overnight, on weekends, while everyone's in meetings. When it fails, the failure goes into a log nobody opens. You find out from a customer, a board member, or a number that suddenly looks wrong. Most AI projects have no smoke alarm at all.

If you're considering an AI agent project — or already in one — these are the questions to ask before you sign anything:

How does it handle "I don't know"? What happens after the fortieth task? Which system does it pull from, and how does it know? Does the test data look like your real data? And the big one: who finds out first when it breaks?

A Skill Is a Workflow You Wrote Down

Christa Campbell — Mon, 11 May 2026 00:00:00 GMT

The most important word in agentic AI right now might also be the most misleading: "skill."

A skill isn't a capability the AI has. It's a workflow you've documented so something else can run it.

I built one last week that turns a 90-minute Monday morning report into a five-minute one. Pulls the data, runs the math, formats the deck, drafts the talking points. Done before I'm on my second coffee.

It works because I sat down and wrote, in plain English, exactly how I'd build that report if I were doing it myself. Where to look. What to count. What "stale" means in this context. Which exceptions to flag and which to ignore. How to structure the executive summary so it doesn't bury the lead.

That document is the skill. The model just runs it.

This is the piece most enterprise AI strategies are missing. The bottleneck isn't model access, compute, or even data. The bottleneck is that most organizations have never written down how their work actually gets done.

The expertise lives in three people's heads, and one of them is retiring in March.

You can't automate a workflow nobody has articulated.

So the real prep for agentic AI isn't a procurement decision. It's a documentation problem. Pick the five workflows you'd most want to delegate, and start by writing them out — not for the AI, for yourself. The skill comes after.

The unglamorous part of agentic AI: half the work is writing down what you already know how to do.

The Dashboard That Updates Itself

Christa Campbell — Tue, 05 May 2026 00:00:00 GMT

The dashboard that updates itself while I'm in another meeting.

Most people are still using AI like a really smart search bar. Ask a question, get an answer, close the tab. Repeat.

That's not where the value is.

The value is in building tools that work for you while you're doing something else. Not chatbots. Systems that go pull the inputs, process them, and update your view of the world while you're in a 1:1 about something completely different.

Here's what I built for myself this week.

A live project health dashboard artifact. It tracks every project I'm running — milestones, risks, decisions, stakeholder sentiment, commitments I've made and haven't closed out yet.

I don't update it. A skill I built pulls the last 72 hours of meeting notes, emails, Slack, and project files tied to each project, and rolls it all into the dashboard. I open it Monday morning and the picture is already current.

So I walk into every leadership meeting knowing where things actually stand — not where the last status deck said they stood three days ago.

This is what agentic AI looks like when it stops being a demo.

It's a tool that knows what sources to pull from, what's signal vs. noise, how to structure the output for the decision I'm actually making, and what cadence to keep so it stays ahead of the work. That last piece is underrated.

The architecture matters more than the model. Claude, GPT, Gemini, open source — pick your stack. What separates a useful agent from a slick demo is the orchestration. Which tools it calls, in what order, with what grounding, and how it knows when it's done.

That's the work. And it's the part most enterprise AI efforts I see haven't really started on yet.