For the last few years, the AI industry has largely followed one direction: build increasingly capable Large Language Models and then use those models for almost everything.

Need to summarize a document? Call an LLM.

Need to write code? Call an LLM.

Need to decide which tool an agent should invoke next? Call an LLM.

Need to determine whether a transaction is risky, whether a workflow should continue, or whether an output needs human review?

Again, call an LLM.

That last category is where things are starting to get interesting.

The recent launch of Jev by TypeSafe AI introduces a different approach: a model designed specifically for making decisions inside software rather than generating text.

And I think the architectural idea behind it may be more important than the headline numbers.

We may be using LLMs for jobs that don’t require language generation

Consider a typical AI agent.

The agent may need to answer questions such as:

“Which tool should I call next?”

“Should I retry this operation?”

“Is this request high risk?”

“Which team should receive this ticket?”

“Does this output satisfy the policy?”

“Should I continue automatically or escalate to a human?”

These are not really writing problems.

They are decision problems.

Yet today we often send the context to a general-purpose language model, ask it to reason about the situation, wait for it to generate tokens, request JSON or another structured format, validate that response and finally convert it into something our application can use.

We are effectively asking a powerful language-generation engine to produce something that eventually becomes:

true

false

approve

reject

tool_A

tool_B

or perhaps a score between 1 and 5.

It works.

But architecturally, it feels expensive.

Enter Jev

TypeSafe AI describes Jev as its first System One Model.

Instead of generating arbitrary strings, the application provides Jev with some state and a set of predefined questions.

Jev then returns typed decisions such as a Choice, Score, or yes/no probability, along with confidence information.

The important difference is that the possible outputs are defined by the application.

Imagine an agent has four possible next actions:

SEARCH

CALL_API

ASK_USER

STOP

A conventional LLM can be prompted to select one of them.

But it is still fundamentally generating text.

Jev approaches the problem differently. The decision space is part of the interface itself. The model evaluates the options and returns a typed result that software can consume directly.

That distinction sounds small.

At scale, it could be significant.

From “AI that talks” to “AI inside software”

One of the most interesting ideas behind TypeSafe is the distinction between intelligence built primarily for humans and intelligence built primarily for machines.

Chat models have been optimized to communicate with people.

They explain.

They summarize.

They generate.

They reason through complex requests.

And that flexibility is incredibly useful.

But software wants something different.

Software wants predictable interfaces.

It wants types.

It wants bounded outputs.

It wants latency it can plan around.

And when uncertainty exists, software needs a way to quantify that uncertainty so it can decide whether to proceed automatically or escalate.

Jev is essentially trying to turn AI judgment into something closer to a software primitive.

Instead of:

State → Prompt → Generated text → Parse → Validate → Decision

the pattern starts to look more like:

State → Decision model → Typed probability → Application logic

That is an interesting architectural shift.

The performance numbers are difficult to ignore

TypeSafe currently prices Jev at $0.042 per million input tokens, with output effectively free.

The company reports end-to-end response times around 70 — 500 milliseconds and says its workflow evaluations have shown gains of up to 193.6× in speed and 444.6× in cost compared with language-model-based approaches.

Those numbers need context.

The evaluations are published by TypeSafe itself, and the company explicitly acknowledges that the largest improvements are likely at the high end of what developers should expect in real production workloads.

That transparency matters.

The more interesting point is not whether every organization receives a 193× improvement.

Even a fraction of that improvement changes the economics of systems making millions of small AI decisions.

If an autonomous workflow makes 20 or 30 judgments before completing a task, latency compounds.

So does cost.

Reducing the cost of each individual judgment can therefore affect the economics of the entire agent architecture.

The ecosystem reaction may be even more interesting than the benchmarks

Jev launched on September 15.

Vercel added it to AI Gateway shortly afterwards, allowing developers to use Jev as a decision model through its AI infrastructure.

Cloudflare also lists typesafe/jev through Workers AI.

Perhaps more tellingly, Vercel reported that within 24 hours Jev had become the fastest-adopted model in AI Gateway history, reaching nearly 13% of its paid teams.

For a model built around a relatively unfamiliar concept, that is notable.

It suggests developers recognize the problem TypeSafe is trying to solve.

LangChain has also started experimenting with Jev as an evaluator for AI agents. In an early test published shortly after the launch, its team found Jev significantly faster and cheaper for the particular evaluation workload it tested, while emphasizing that the results were still early and narrow.

This is exactly the kind of experimentation that should happen next.

The real validation of Jev will not come from launch benchmarks.

It will come from production systems.

This doesn’t mean the LLM disappears

I think this is one of the most important points.

Jev is not necessarily an alternative to GPT, Claude or other frontier models.

It may be a complement to them.

A future AI system could look something like this:

The LLM handles complex reasoning, conversation, code generation and content creation.

A decision model handles routing, classification, policy checks, scoring, verification and agent control flow.

Traditional deterministic code handles everything that can be expressed reliably as normal software logic.

Humans handle decisions where confidence falls below an acceptable threshold.

That gives us a much more interesting architecture than simply putting an increasingly powerful LLM in the middle of everything.

The question becomes:

What is the cheapest and most reliable form of intelligence required for this particular step?

That is a very different engineering mindset.

The type-safety claim also deserves some nuance

TypeSafe emphasizes that Jev cannot produce an output outside the schema defined by the developer.

That is genuinely useful.

An agent choosing between four tools cannot suddenly return a fifth tool that does not exist.

But we should distinguish type correctness from decision correctness.

A model can return a perfectly valid value and still make the wrong decision.

For example, returning:

ALLOW

may satisfy the schema perfectly while still being the wrong judgment.

This is why the probability and confidence component may ultimately be more important than the typed output itself.

Production systems need policies such as:

high confidence → automate

medium confidence → run additional verification

low confidence → human review

That makes AI uncertainty part of application architecture instead of pretending uncertainty does not exist.

This could matter enormously for enterprise AI

Enterprise AI discussions often focus on which frontier model is smartest.

But organizations operating large platforms care about another set of questions:

How predictable is the system?

How much does each decision cost?

What happens when usage increases by 100×?

How much latency does AI introduce into a transaction?

Can decisions be audited?

Can uncertain cases automatically be escalated?

Can AI be inserted into existing deterministic workflows without turning the entire application into an unpredictable agent?

Those questions become increasingly important as AI moves from copilots into operational systems.

A specialized decision layer could become particularly useful in areas such as cybersecurity alert triage, customer-service routing, fraud screening, software delivery workflows, agent guardrails, risk classification and automated quality checks.

Not because those tasks don’t require intelligence.

Because many of them require judgment without requiring prose.

And then there is Jevons Paradox

The name Jev itself is a reference to economist William Stanley Jevons.

Jevons observed that making coal usage more efficient didn’t necessarily reduce coal consumption. Greater efficiency made coal economically useful in more situations, which ultimately increased overall consumption.

TypeSafe is applying the same idea to intelligence.

If an AI decision becomes dramatically cheaper, developers may not simply spend less money making the same number of decisions.

They may start putting intelligence into places where it was previously economically irrational.

A workflow that currently contains five AI decisions might eventually contain fifty.

A security platform might evaluate every event rather than only suspicious ones.

An agent might continuously score its own actions.

Applications might make thousands of tiny semantic judgments in the background that no developer would consider sending to a frontier LLM today.

That could be the most important implication of Jev.

The bigger story may not be cheaper AI.

It may be far more AI calls.

A new primitive for AI architecture?

It is still extremely early.

Jev was released only days ago.

Its most dramatic benchmark numbers come from TypeSafe’s own evaluations, and real-world accuracy across different domains still needs much broader independent testing.

Production teams should validate it against their own labeled data, monitor confidence calibration and introduce automation gradually rather than assuming typed output automatically means correct output.

But the architectural question TypeSafe is raising is compelling.

For years, we have effectively treated the LLM as the CPU of every AI application.

Perhaps that abstraction is too broad.

Maybe intelligent systems will increasingly consist of multiple specialized forms of intelligence:

models that reason,

models that generate,

models that perceive,

and models that decide.

If that happens, Jev may be interesting not because it is another new AI model.

It may be interesting because it is challenging one of the assumptions we have quietly built into modern AI architecture:

that every intelligent decision needs to begin with a language model generating words.

And that assumption may be ready for a rethink.

Coding agents have become reliable executors. Give one a well-formed ticket and it will produce a decent pull request. Give one a loose idea for a project spanning weeks and it flounders, because the work does not fit in a context window and nobody has decided what the work is yet.

Matt Pocock has released a skill for exactly that stage. It is called [/wayfinder](https://github.com/mattpocock/skills/blob/main/docs/engineering/wayfinder.md), and it belongs to his AI Skills for Real Engineers collection, which has over 220,000 stars on GitHub. Its purpose is to chart a route through work whose destination is not yet visible.

The problem is context, not reasoning

Pocock’s account of why he built it does not read as a complaint about model quality.

He had already invested in scheduling work for away-from-keyboard agents, turning specs into tickets so those agents could run overnight. The bottleneck he hit was upstream of that. He described the planning stage as onerous, because it forced constant session management, down to counting how many tokens he was into his context window and how deep a thread had gone.

What he wanted was an orchestrator layer that would, in his words, “split this out into multiple different threads, do prototyping, do research and pull it all back together”. Planning would stop being a single long conversation that degrades as it fills the window.

That framing matters for anyone building agent workflows. The failure mode being addressed is not that the model reasons badly about architecture. It is that a human trying to plan inside an agent session spends attention on budgeting the session rather than on the decisions.

The map, the ticket and the session

The design that came out of it rests on three words, and the skill’s published documentation treats those words as part of the engineering.

A **map** is a single issue on the repository’s issue tracker, carrying the label `wayfinder:map`. It is an index rather than a store. It holds a Destination section describing what the effort is finding its way to, a Notes section, a Decisions so far list with one line per closed ticket, and two further sections covered below.

A **ticket** is a child issue of that map. Its body is a question whose resolution is a decision, not a slice of the build to execute. Each ticket body is sized to one 100K token agent session.

A **session** works one ticket. The skill instructs a session never to resolve more than one ticket, with research as the only exception. A session claims a ticket by assigning it to the developer driving the map before any work begins, so that concurrent sessions skip it.

Pocock calls these leading words, and he is deliberate about them. He has been building an AI coding dictionary so that every skill he ships runs on the same terms, and he has rebuilt his courses to use it. The reasoning is that an agent given inconsistent vocabulary produces inconsistent behaviour, and that fixing the vocabulary is cheaper than fixing the behaviour afterwards.

Four ticket types, split by who has to answer

Every ticket carries a `wayfinder:<type>` label, and the four types divide along a line that most agent workflows blur.

**Research** tickets run unattended. They cover reading documentation, third-party APIs or local knowledge bases to surface a fact that a decision is waiting on.

**Prototype** tickets are human in the loop. They exist to raise the fidelity of a discussion by producing something cheap and rough to react to, whether that is an outline, a stub or some throwaway interface code. They are the answer to questions of how something should look or behave.

**Grilling** tickets are the default case, and they are conversation. The skill is blunt about the boundary here. A grilling agent that answers its own questions has broken the contract, because the point of the ticket is the exchange with a human who speaks for themselves.

**Task** tickets are the odd one out, because they do rather than decide. Signing up for a service so its API can be judged, provisioning access, moving data so its shape can be seen. They earn their place by unblocking a decision, and the resolution records facts that later tickets depend on, such as where credentials now live or how many rows arrived.

That split is the most portable idea in the whole design. Any team running agents at scale eventually needs to mark which questions an agent may settle alone and which require a person, and doing it with a label on the ticket is about as cheap as that marking gets.

What deliberately stays off the map

The section that separates this from an ordinary planning template is the one for work that is not ready to be planned.

Pocock’s central metaphor is the fog of war, the idea that you cannot decide everything at the start, and that resolving one decision reveals the next. The map has a **Not yet specified** section where that dim view is written down, covering suspected questions and areas to revisit once the frontier reaches them.

The rule for what goes there is precise. The test is whether you can state the question sharply now, not whether you can answer it now. A question you can phrase becomes a ticket even if it is blocked. A question you cannot phrase stays in the fog, and the skill warns against pre-slicing that fog into ticket-sized pieces, since one patch may graduate into several tickets or none at all.

There is a companion section for work ruled beyond the destination, which is closed rather than deferred and never graduates back in.

The practical effect is a backlog that stays honest. Most planning artefacts drift because they fill with speculative items nobody can act on, and every review meeting spends its time rediscovering that.

When not to use it

Pocock supplies his own limit, which is a better sign of a real tool than any launch post.

His other skill, grill-me, is the one to use “in cases where you feel like you can plan the whole thing in a single session, and you need to align before you go”. Most small features fit that description. If you can see the path ahead and only want the agent aligned with it, a map on the issue tracker is overhead with a label attached.

Wayfinder is for the case where the path is not visible. It covers a narrower slice of work than the current enthusiasm for planning frameworks suggests, and the narrowness is the point.

Planning is where the quality of agent output is actually decided, and it remains the stage most teams leave unstructured.

Source: [Matt Pocock](https://github.com/mattpocock/skills/blob/main/docs/engineering/wayfinder.md)

A teammate opens a ticket: “improve auth flow when users have multiple sessions.” Three hours later, Claude Code opens a PR. It moves session storage from Postgres to Redis. The diff is clean. CI passes. The reviewer approves.

Two days later, on-call gets paged. The actual problem was that users with five tabs open were seeing a confusing error message. A UI fix, maybe an hour of work. The PR rewrote the session layer of an auth system. It worked. It wasn’t wrong, exactly. It just had nothing to do with the problem.

This is the failure mode nobody talks about with AI coding agents. They don’t crash. They don’t refuse. They produce something plausible from whatever you gave them, and the cost lands on the reviewer who now has to decide whether to merge a refactor they didn’t ask for or send the agent back and pay the token bill again.

The thing we stopped doing

There was a concept in agile called Definition of Ready. Before a ticket entered a sprint, it had to clear a checklist: acceptance criteria, scope, risk, test expectations. In practice, most teams skipped it. Humans are good at filling in gaps. A senior engineer reads “improve auth flow” and asks two clarifying questions in standup. Done.

Agents can’t ask. Or rather, they can, but the ones we’re shipping to production right now mostly don’t. They guess. And their guesses are confident, well-formatted, and frequently in the wrong file.

Definition of Ready was optional when the worker was a human. With an agent in the loop, it’s the cheapest checkpoint you have.

What agent-ready does

agent-ready is a linter for tickets. You point it at an issue (a local JSON file, a GitHub issue, eventually Jira and Linear) and it runs 12 rules. If the ticket has gaps, it tells you exactly which ones, in 50 ms. Before any tokens get spent.

Here’s what it looks like on the ticket from the opening:

$ npx @agentlane/agent-ready check issue-482.json

agent-ready v0.4
checking: issue-482.json

  ✗ has-acceptance-criteria     no acceptance criteria found
  ✗ has-definition-of-done      no DoD section found
  ✗ has-risk-classification     no risk label or field
  ✗ has-test-expectations       tests not mentioned
  ✗ no-ambiguous-verbs          found "improve" (line 1)
  ✗ restricted-paths-declared   touches src/auth/* without risk:high
  ✗ body-min-length             42 chars (min 200)
  ✗ t-shirt-size-present        no size set
  ✓ has-repo-target
  ✓ no-tribal-knowledge
  - has-design-link             skipped, not required
  - links-resolve               skipped, opt-in

8 failed, 2 passed, 2 skipped.
not ready for agent. fix the gaps above or assign a human.

That’s the whole product, more or less. Deterministic rules, plain output, exit code 1 if anything fails.

How it plugs into a real workflow

The CLI is for local checks. The interesting part is the GitHub Action. Drop this in .github/workflows/agent-ready.yml:

yaml

name: agent-ready
on:
  issues:
    types: [opened, edited, labeled]

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: agentlane/agent-ready@v0
        with:
          format: markdown
          comment: true
          label: agent-ready
          token: ${{ secrets.GITHUB_TOKEN }}

When a new issue is opened, the Action runs, posts a comment listing the failed rules, and adds (or removes) the agent-ready label. Then you gate your agent invocations on the label. @claude only triggers on labeled issues. @copilot workspace tasks only pick up labeled tickets. The agent never sees an unready issue. The token bill drops. The PR queue stops filling with confident misreadings.

Four output formats ship: text for terminals, markdown for the GitHub comment, JSON for piping to other tools, and SARIF if you want findings to land in code scanning.

Three rules that surprise people

Most of the 12 rules are obvious. Acceptance criteria, definition of done, t-shirt size. These three are the ones engineers ask about.

no-ambiguous-verbs. It flags words like “improve,” “optimize,” “clean up,” “refactor,” “enhance.” These verbs feel actionable to humans because we mentally constrain them with context. An agent reads “improve performance” and might rewrite your database layer. Banning the verb forces the author to say what they actually mean: “reduce p95 latency on /search below 200ms.”

no-tribal-knowledge. It flags phrases like “as discussed,” “you know the one,” “like we did last time,” “the usual approach.” These are perfectly normal in a Slack thread between two engineers who share context. An agent has no Slack history. The phrase is a tell that the ticket is missing the actual content of “the discussion.”

restricted-paths-declared. This is the one that wins people over. If your ticket touches src/auth/*, src/payments/*, or anything under an IAM directory, the rule requires an explicit risk:high label. The premise is simple. You might be fine with an agent rewriting your CSS without flagging it. You probably want a louder signal before it touches the session middleware. The rule is configurable. You point it at the paths that matter to you.

What it doesn’t do

agent-ready is a deterministic linter. It does not call any model, send your tickets anywhere, or judge whether your acceptance criteria are good. It checks that they exist, that they’re not full of “as discussed,” and that the ticket has the shape an agent needs.

That’s intentional. An LLM judge is slow, costs money, and can be wrong about whether a ticket is ready for an LLM, which is funny but not useful. A fast deterministic check that runs in 50 ms is something you can put on every issue, every edit, without thinking about budget.

It also doesn’t read your repository. It doesn’t validate that the acceptance criteria match your codebase. That’s a different tool. agent-ready is a gate, not a reviewer.

Trying it

npx @agentlane/agent-ready check <your-ticket.json>

Or wire up the Action and let it run on every issue. The repo is at github.com/agentlane/agent-ready, MIT licensed, twelve rules in src/rules, write your own if you want.

agent-ready is the first piece of a small family of tools (agentlane) aimed at making the agentic SDLC observable and gateable from local dev through to PR review. This one is the front gate. Bad ticket in, exact gaps out, before any tokens are spent.

Anthropic shipped Claude Opus 4.8. Most of the coverage will focus on benchmark improvements and the 2.5× speed boost in fast mode.

I care about something else: the new ‘dynamic workflows’ feature in Claude Code.

It lets the model decompose very large-scale problems into coordinated subtasks. That is a pattern that was previously hard to automate. Think about a monolith-to-microservices migration. You could break it into file-by-file tasks, with the model coordinating changes across hundreds of files. Or tracing dependencies through a legacy system to generate documentation.

This is not just a faster model. It is a different way to structure work.

Which large-scale chore would you automate first?

What shipped in Opus 4.8

Anthropic released Claude Opus 4.8, an upgrade from Opus 4.7. The source material from [Anthropic](https://www.anthropic.com/news/claude-opus-4-8) confirms improvements across benchmarks and positions the model as a more effective collaborator. Three features define this release: dynamic workflows in Claude Code, a controllable effort setting on claude.ai, and a fast mode that is now 2.5× quicker and 3× cheaper than the previous version. These are practical adjustments, not just headline numbers. A team iterating on CI test generation can use fast mode to reduce cycle time without altering their pipeline logic. An engineer who needs a quick linting suggestion can dial down the effort, then request a comprehensive architectural review later with higher effort. The tools are available, and they slot into existing workflows rather than demanding new ones.

Dynamic workflows change how you attack large problems

The feature that matters most is dynamic workflows inside Claude Code. It is not a faster way to write a single function. It is a mechanism for splitting massive tasks into subtasks and then coordinating them. The source describes it as a feature that “allows it to tackle very large-scale problems.” That is thin language for something genuinely useful. In practice, a maintainer can ask Opus 4.8 to trace dependencies across a legacy system, generating documentation module by module. A developer can break a monolith into microservices, treating each extraction as a coordinated step where the model tracks what changed and what still needs attention. Even an open-source maintainer reviewing a large pull request can use it to split test generation across components, covering edge cases systematically. None of this is magical, but it is a structural shift from linear prompting to task orchestration. The model is managing state across steps, not just completing a prompt.

Speed and cost matter for real workflows

Fast mode is 2.5× faster and 3× cheaper. Those figures come directly from the announcement and they matter when you are running something in a CI pipeline or inside an IDE where latency kills momentum. A team running iterative test-generation cycles in a CI tool will see shorter wait times, which keeps the feedback loop tight. A developer who wants a model inside their IDE for routine code review or SQL query generation will notice that the response arrives before they lose context. The cost reduction makes it viable to run more frequent checks. Controllable effort on claude.ai means you can match the compute to the task. Quick linting? Low effort. Architectural review? High effort. That is a sensible allocation of resources, and it reflects an understanding that not every coding interaction is a PhD-level formal verification problem.

Where this fits in the landscape

The announcement does not publish specific benchmark names or scores. Anthropic says Opus 4.8 builds on Opus 4.7 with improvements across benchmarks, without detailing results on SWE-bench, HumanEval, or other coding evaluations. That is worth noting because it means the evidence is general, not granular. The dynamic workflows feature points towards large-codebase navigation, but the source does not explicitly claim improved performance on repository-scale tasks beyond what the orchestration pattern enables. This release reads more as a refinement than a step change. The upgrade path from Opus 4.7 is natural: you get the same model family with better speed, lower cost, and a new tool for decomposing large work. Developers who wanted a faster, cheaper assistant for their IDE or CI system will find it here. Those who want to automate a chore at scale now have a better hammer. The hammer, for once, knows how to split the rock.

Governance, MCP, budget models, legacy codebases, culture, regulation and 30+ tools, from someone who’s actually built this.

Last year something changed in how I think about pipelines. Not because the tooling changed, or the process changed. Because the entity pushing code through the pipeline is no longer always a human. That shift has implications most teams haven’t worked through yet. This is what I’ve found so far.

I’ve been running experiments with agentic workflows inside a real enterprise SDLC process. Orchestrator agents decomposing work, subagents executing in parallel, all running through real CI/CD with CodeQL, SonarCloud, and branch protection as guardrails. Not a demo environment. The actual pipeline.

One session. One problem statement. Here’s what came out:

• 14,251 lines of production code across 117 files
• 69 automated tests, TDD-style. 83.5% coverage
• 60 GitHub Issues created, tracked, and closed by the agent
• SSRF vulnerability introduced, caught by CodeQL, fixed autonomously
• 7 code review cycles, 81 comments, all self-resolved
• 11/11 CI gates passing. ~5 human decisions in the entire run

(For anyone wondering: these numbers were pulled from repo stats and CI outputs, not estimated.)

Impressive output. But the output isn’t what I keep thinking about.

What I keep thinking about is what this revealed about how the pipeline needs to change when agents are the ones running through it.

What Changes When the Actor Isn’t Human

A human engineer who gets a CodeQL warning makes a judgment call. They read it, assess the risk, and decide how to respond. They bring context and experience to that decision.

An agent does exactly what it’s configured to do, and nothing more. If the gate is advisory, it proceeds. If it’s blocking, it stops and tries to fix it. There’s no judgment layer. The pipeline configuration becomes the judgment.

In my session, the agent introduced an SSRF vulnerability. It would have made it to the PR if CodeQL had been set to warn rather than fail. The agent had no intuition it had done something dangerous. The gate was the only thing that caught it, and once it blocked and reported the finding, the agent fixed it correctly.

That experience changed how I think about gate configuration. Things I used to treat as advisory, because I trusted developers to use their discretion, probably need to be explicit policy when agents are involved. Agents don’t exercise discretion. They execute configuration.

This is where “policy-as-code” stops being a buzzword and becomes a requirement. For humans, policy can be guidance. For agents, policy has to be executable, testable, and enforced. If it isn’t encoded in your gates, it effectively doesn’t exist.

I don’t think there’s one right answer for every team. But I do think it’s worth being deliberate about which gates are load-bearing and which are genuinely optional, and encoding that decision explicitly rather than leaving it to chance.

Things I Think Need More Attention

These are areas where I’ve seen gaps in how teams are approaching agent integration. Not prescriptions, just honest observations.

Agent observability. When a session fails, I want to know what the agent actually did: which tools it called, where it retried, what its token consumption looked like at each step. Without that visibility, failures are hard to diagnose and configurations are hard to improve. Most teams I’ve seen are logging agent sessions crudely or not at all. I think this will matter more as usage scales.

Centralised agent learning. This is the part I think gets missed most. When an agent on Team A figures out a better way to handle a retry loop, or learns that a particular prompt pattern causes it to go in circles, that knowledge lives and dies in that session log. Team B hits the exact same problem two weeks later and burns the same tokens learning the same lesson from scratch.

At scale this is a real cost and time problem. If you can centralise what agents learn across sessions, failure patterns, effective prompt strategies, tool call sequences that consistently work, configuration choices that reduce retry rates and feed that back into the shared config registry, you stop paying for the same mistakes repeatedly across every team. One agent’s hard-won session insight becomes every agent’s starting point. The tooling to do this well is still early, but even a simple shared runbook of observed failure modes, maintained centrally and updated as teams encounter new ones, is better than everyone starting cold.

Permission scoping for agent roles. Agents call tools, and those tools need credentials. It’s easy to give an agent broad access to make setup simpler but that’s a risk that compounds with every session. I’ve found it worth the effort to scope permissions tightly per agent role: the build agent gets what it needs to write and commit code, the review agent gets what it needs to read and comment, nothing more. Treating agent credentials with the same rigour as service accounts seems right.

Centralised config over team-level improvisation. When each team configures their own agents independently, you end up with divergent prompt strategies, inconsistent permission models, and no way to learn across teams. I’ve seen this happen with cloud adoption too, and it takes a long time to unwind. A centralized shared baseline of agent configurations makes a big difference. It doesn’t need to be elaborate. Even a simple, version-controlled set of approved configurations for common agent roles is better than every team starting from scratch.

Alongside configuration, there’s a second governance surface teams should standardize: repo-level agent instructions. Formats like AGENTS.md are useful because they give you a predictable, version-controlled place to tell coding agents how to work in your repo (setup commands, test commands, style rules, boundaries, and what “done” means).

MCP: Worth Understanding Before Your Teams Fragment It

Model Context Protocol is becoming the standard interface between agents and the tools they operate inside. Instead of each team building custom integrations with GitHub, JIRA, Figma, SonarCloud, and whatever else is in the stack, MCP gives agents a consistent way to interact with all of them.

In practice, the integrations I’ve found most valuable:

• Source control so agents can branch, commit, and PR through a governed interface rather than direct API calls
• Issue tracking so agents stay in sync with the planning system your teams are actually looking at
• Design tools so agents read specs directly, rather than relying on someone to translate them
• Quality & security so agents query findings directly and can act on them without parsing CI logs
• Observability so deploy agents can make decisions based on live metrics

The thing I’d caution against: letting each team build their own MCP integrations independently. You end up with the same fragmentation problem as unmanaged config. Having a shared, governed set of MCP connections that teams consume from a central place makes more sense to me, even if “centralised” simply means version-controlled and reviewed.

One important industry signal here: MCP is now stewarded under the Linux Foundation’s Agentic AI Foundation (AAIF), alongside other agentic standards/projects. That matters because neutrality and open governance are exactly what you want for something that will sit at the center of tool access.

The Budget Conversation Nobody Is Having Yet

This one surprised me. The financial implications of agentic AI are genuinely different from anything the existing delivery governance models were built for.

Traditional project budgets are denominated in man-days. Agent sessions invoice in token consumption and API calls. A session that produces three weeks of engineering output might cost $200 in API fees or $2,000 if the agent ran inefficient retry loops or used an unnecessarily powerful model for a simple task. Finance currently has no framework for evaluating either number.

A few things that seem to help:

Session budgets with a ceiling. Every agent run should have an explicit token limit, pausing and asks for authorisation to continue rather than running indefinitely. The expense policy equivalent: small amounts autonomously, larger amounts need sign-off.

Model routing by task type. Not every task needs the most capable, and most expensive, model. Simpler, well-defined tasks can run on lighter models at significantly lower cost. Getting this right at the configuration level rather than leaving it to ad-hoc choices makes a meaningful difference at scale.

Cost attribution that matches how you already track cloud spend. Tagging agent API costs with project, team, and sprint references means the spend shows up in the same FinOps dashboards finance already looks at. It makes agent costs legible without requiring a new reporting framework.

Circuit breakers for runaway sessions. An agent in a retry loop on a hard problem can accumulate significant cost quietly. An automatic pause at a budget threshold, with a notification, prevents that.

I’ll be honest, I’m still working out the right framework here. But the metrics I’ve found most useful in practice so far: story points completed per session (mapped against your team’s existing velocity baseline), review cycles resolved without human escalation, CI gate pass rate on first attempt, and coverage delta per session. None of these are perfect. But they’re observable, they’re already tracked in most pipelines, and they give you something to trend over time rather than a one-off impression. The man-day framing doesn’t fit anymore, but the answer isn’t no metrics, it’s different ones.

The Part Most Articles Skip: Legacy Codebases

Almost everything written about agentic AI assumes a greenfield codebase. A clean repo, well-defined boundaries, modern tooling, documented architecture. My PoC was greenfield too, and I’m aware that makes it the easy case.

The reality most engineering teams live in is different. Years of accumulated decisions. Modules nobody fully understands anymore. Tribal knowledge that never made it into documentation. Business logic embedded in code that predates half the current team.

Agents struggle with this in ways that aren’t obvious until you run them against it. They can’t infer what they can’t see. Undocumented constraints get violated confidently. Legacy integration patterns get refactored in ways that are locally correct and systemically breaking.

I think this is where governance architecture matters most, not least. The more opaque the codebase, the more important it is that your quality gates are rigorous, your acceptance criteria are explicit, and your human review points are well-placed. The agent can’t compensate for missing context. Your process has to.

I haven’t run these experiments at the scale of a genuinely complex legacy codebase yet. It’s the next thing I want to test properly before I have a confident view. But I’d be cautious about anyone claiming the same results in that environment without having actually tried it.

The Resistance Nobody Talks About

The technical governance problem is the one engineers naturally focus on. But in most organisations, the harder problem is cultural.

Experienced engineers have strong intuitions about quality, about what “done” looks like, about which shortcuts are acceptable. Those intuitions were built over years of shipping software and living with the consequences. When an agent produces code that passes all the gates but somehow doesn’t feel right, that instinct matters and it’s hard to honour in an automated process.

The risk I’ve seen is two-sided. Some engineers disengage from the review process because the agent “already checked it.” Others over-intervene, effectively doing the review twice and eroding the efficiency gain. Neither response is wrong exactly, but both reflect a process that hasn’t found its equilibrium yet.

What seems to help: being explicit about what humans are reviewing for that the gates can’t check. Architectural coherence. Intent alignment. Things that require context the agent doesn’t have. Framing the human review as a different kind of check, not a redundant one, seems to change how people engage with it.

I don’t have a clean answer here. But I think teams that ignore the cultural dimension and focus only on the technical setup will find their adoption stalls in ways that are hard to diagnose.

There’s also a skills question underneath the cultural one that doesn’t get named directly. Operating and governing agentic workflows requires a different profile than traditional engineering. Writing tight acceptance criteria that agents can execute against is a discipline most engineers haven’t been trained in. Reading and evaluating agent session traces requires familiarity with token-level debugging most teams haven’t needed before. Configuring governance layers, gates, permission scopes, MCP integrations, requires someone who sits across platform engineering, security, and delivery. Those skills exist in most organisations but rarely in the same person. Being explicit about where those gaps are before you scale is more useful than discovering them mid-rollout.

The Regulatory Dimension

This is one I’m still getting my head around, and I suspect it will become unavoidable faster than most engineering teams expect.

When a human engineer introduces a bug, the accountability chain is clear. When an agent does, it’s murkier. Who is responsible for the acceptance criteria that didn’t capture the edge case? The engineer who wrote the story? The team that configured the agent? The tool vendor? Regulators in financial services, healthcare, and other sensitive sectors are starting to ask these questions, and the answers will have architectural implications.

The governance layer I’ve been describing, blocking gates, auditable decision logs, explicit human approval points, version-controlled configurations, isn’t just about engineering quality. It’s also the foundation of a defensible audit trail. If a regulator asks “who decided this code should go to production and on what basis,” you want to be able to answer that clearly.

Gartner projects that a significant share of AI use cases will be abandoned in the next few years, not because the technology fails, but because governance frameworks weren’t built alongside the capability. I think that’s a real risk, and I think the teams building auditable, governed agentic processes now are building something that has value beyond engineering efficiency.

It’s worth thinking about early, before the regulatory pressure makes it urgent.

What I’d Suggest for Teams Starting Out

Not a framework. Just what I’d do based on what I’ve seen work and what I’ve seen go wrong.

Get the governance layer right before you scale. Configure blocking gates, not advisory ones, for anything you’d want a human to catch. It takes days and prevents months of problems.

Start with MCP integrations for two or three tools, specifically source control, your issue tracker, your quality scanner. Get those working reliably. Everything else can follow.

A centralized shared baseline of agent configurations makes a big difference. It doesn’t need to be elaborate. Even a simple, version-controlled set of approved configurations for common agent roles is better than every team starting from scratch.

Run a real cost baseline with one team before rolling out broadly. Understand what governed agent usage actually costs in your environment before you multiply it by 20.

And start building outcome-based delivery metrics now, while you still have both human and agent contribution to calibrate against.

The organisations building governed agentic capability now aren’t just moving faster. They’re setting the standards, the patterns, and the expectations that everyone else will inherit. That’s worth doing carefully. I’m still figuring a lot of this out in real time. If you’re working through the same questions, governance architecture, MCP integration, cost models, cultural adoption, I’d genuinely value comparing notes.

Drop a comment or connect.

REFERENCES AND RESOURCES

Everything mentioned in this article, in one place. No affiliate links, no sponsorship.

Standards and governance

• Model Context Protocol (MCP): https://modelcontextprotocol.io
• Linux Foundation AAIF: https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation

Agent orchestration frameworks

• Google ADK: https://google.github.io/adk-docs
• LangGraph: https://langchain-ai.github.io/langgraph
• CrewAI: https://crewai.com
• Microsoft AutoGen: https://microsoft.github.io/autogen
• Camunda MCP Client (early access): https://docs.camunda.io/docs/components/early-access/alpha/mcp-client/
• mcp-agent: https://github.com/lastmile-ai/mcp-agent

MCP servers and catalogs

• Official MCP servers: https://github.com/modelcontextprotocol/servers
• MCP Registry repo: https://github.com/modelcontextprotocol/registry
• Bifrost gateway: https://github.com/bifrost-gateway/bifrost
• Azure MCP Server (Microsoft docs): https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/get-started
• Composio MCP directory (note: deprecation/transition): https://mcp.composio.dev
• Composio (Rube MCP direction): https://github.com/ComposioHQ/composio

Remote MCP hosting guides

• Cloudflare remote MCP servers: https://blog.cloudflare.com/remote-model-context-protocol-servers-mcp/
• Google Cloud Run: host MCP servers: https://docs.cloud.google.com/run/docs/host-mcp-servers
• AWS guidance for deploying MCP servers: https://aws.amazon.com/solutions/guidance/deploying-model-context-protocol-servers-on-aws/

Agent observability and evaluation

• LangSmith: https://smith.langchain.com
• Langfuse: https://langfuse.com
• Helicone: https://helicone.ai
• Datadog LLM Observability: https://docs.datadoghq.com/llm_observability/
• Braintrust: https://www.braintrust.dev
• Arize Phoenix: https://phoenix.arize.com

Agentic SDLC platforms

• Entire launch post: https://entire.io/blog/hello-entire-world/

You’ve probably seen OpenClaw

A personal AI assistant that runs on your laptop, lives in your chat apps, has memory, and actually does things. The indie agentic AI wave, captured in one project. Karpathy quoted it. TechCrunch covered it. The creator joined OpenAI.

But OpenClaw was never built for the enterprise — and it doesn’t pretend to be. “Not enterprise. Not hosted. Infrastructure you control” — that’s how its own users describe it.

The enterprise version of that idea has to look very different.

It has to live inside the tenant. Governed. Audited. Permission-scoped. Meeting the team where the team already works.

And here’s the truth most enterprises are sitting on:

They are already practically living inside M365.

Teams. SharePoint. Outlook. The planning tool. GitHub. Copilot Studio. M365 Copilot in Teams as the interface.

Other paths exist — NeMo, MCP-based agent frameworks, LangGraph, custom-built stacks. They’re real. They’re powerful. But they need to be built.

M365 is already there.

That makes it the fastest, most available path to enterprise agentic AI today.

That’s the path I chose. That’s the part I want to share.

“The tools are already in the room. The work is connecting them.”

The work around the work

A lot of platform engineering time goes into the work around the work.

Been there?

An engineer leaves a meeting and spends time turning a long Teams thread into tickets.

The same blocker gets raised in multiple channels.

Context lives across where work is discussed, documented, planned, built, and shipped — “The tools may be connected, but the reasoning rarely is.”

All of this is necessary.

But it should not consume the best energy of a platform engineering team.

Why I built a DevOps Copilot

So I started experimenting with a DevOps Copilot using Microsoft 365 Copilot Studio — connected to collaboration and engineering context.

The idea was simple:

Can we help engineers spend less time navigating work and more time creating value — improving platforms, automating repeatable work, and solving problems that actually matter?

This was not about creating another chatbot.

It was about taking the work that already happens across meetings, chats, follow-ups, support requests, and GitHub — and making it easier to understand, classify, assign, track, and improve.

What the agent connects to

The important part: the team does not need to leave its normal flow.

The agent sits inside Microsoft Teams, where meetings, chats, follow-ups, and decisions already happen — and connects that context with GitHub Copilot so work can move from conversation to action, and eventually from action to code.

That matters because adoption usually fails when teams need to jump into another portal, another form, or another workflow just to get help.

The value is in meeting the team where the work already happens.

The three hats: Scrum Master, PO, Senior Platform Engineer

The agent starts wearing different hats.

Scrum Master hat

Summarize stand-ups, capture actions, track follow-ups, and surface early risks from what the team is already discussing.

A blocker raised in a stand-up should not disappear after the meeting.

A follow-up discussed in chat should not depend only on someone remembering to create a task later.

PO hat

Draft better stories using existing goals, past decisions, and team context, with clearer acceptance criteria and human approval before anything is created.

The point is not to generate generic user stories.

The point is to use the team’s actual context so the first draft is closer to what the team really needs.

Senior platform engineer hat

Reinforce engineering discipline using existing standards and runbooks, spot repeated requests, and highlight automation opportunities.

This is where it becomes more interesting.

If the same request keeps coming back, maybe it should not remain a ticket forever.

Maybe it should become a reusable workflow.

Maybe it should become self-service.

Maybe it should eventually be handed to an agent.

A few moments that made this real

The three hats sound conceptual on paper. Here’s what they actually looked like in my team’s day-to-day:

The real team status — including what was hidden in chat

I asked the agent: “What’s the real status this week?”

The agent didn’t just pull from the board.

It correlated updates across conversations, boards, and delivery signals for progress that hadn’t been reflected yet — an engineer who finished a task in chat but hadn’t moved the card, a blocker raised on Monday and quietly resolved by Wednesday, a PR merged while the task still showed “In Progress.”

“The board shows what people remembered to update. The agent showed what actually happened.”

The senior engineer, in your pocket

One of my engineers hit a pipeline issue and needed guidance on rollback steps, security group configuration, and deployment standards.

Normally — wait for the senior engineer or tech lead. Sometimes hours.

Instead, the agent — wearing its Senior Platform Engineer hat — pulled from runbooks, architecture decision records, past incident resolutions, and engineering standards, and gave a contextual answer immediately.

“The senior engineer’s knowledge stops living in one head.”

Junior engineers move faster. Senior engineers stop being a bottleneck.

Performance conversations grounded in what metrics don’t show

KPIs and dashboards already tell one story — tickets closed, PRs merged, deployments shipped.

But the real signal in a team usually lives outside metrics.

Who steps in to unblock a teammate without being asked.

Who quietly mentors the junior engineers.

Who picks up the unglamorous work nobody assigned them.

Who shows up for other teams during a tough migration.

Who keeps calm in an incident and pulls people together.

That kind of contribution rarely makes it into a dashboard — but it’s what actually holds a team together.

So I asked the agent to surface collaboration and operational context often missed by delivery metrics — cross-team coordination, escalations supported, incident follow-ups, migration support, and contributions visible in shared work threads.

The goal was not employee monitoring or automated evaluation.

It was to give managers better context around the work that often holds teams together but rarely appears cleanly in dashboards.

Not ratings. Not opinions. Just the real context behind the numbers.

The judgment stayed with me — but it was grounded in how the team actually showed up for each other, not only in what the dashboards remembered.

Orchestrating a risky cross-team change

One of my engineers needed to make a security change to shared pipelines we own — temporarily breaking builds for every consuming team.

The agent became the orchestration layer.

Notified affected teams. Coordinated a build freeze. Tracked completion. Sent the all-clear.

Every step visible. Nobody surprised.

Risky cross-team changes usually fail on communication, not technology.

From email, chat, and meeting → fully structured work in minutes

A request came in via email. Details were discussed in a meeting. Follow-ups landed in chat.

I asked the agent: “Create everything for this.”

Within minutes — full Epic → Feature → Task hierarchy, acceptance criteria from the team’s Definition of Done, engineering standards baked in (observability, rollback, security, documentation), engineers assigned based on availability and expertise.

One “Yes” — and everything was created, linked, and visible.

What used to take an hour of board management happened in one conversation.

Where this fits — brownfield, ops, and the upstream stuff nobody demos

Most agentic AI demos you’ll see are greenfield. New product. Clean codebase. Empty backlog. No incidents. No legacy. No ops baggage.

Real enterprises don’t look like that.

They look like brownfield — years of runbooks, incident history, support tickets, half-documented standards, platform teams keeping legacy alive while building new things on top. Run-the-bank work. Operations queues. The unglamorous middle of the SDLC that nobody puts in a keynote.

Here’s the surprise: this is where the approach actually shines.

The runbooks are already there. The incident history is already there. The repeated tickets are already there. The institutional knowledge is already there — sitting in SharePoint, in chat threads, in resolved tickets, in PRs going back years.

Brownfield isn’t the obstacle. It’s the data.

And it goes further upstream too. Everyone is talking about coding agents and SDLC automation, but very few people are talking about the BRD layer — the business requirements, the discovery conversations, the back-and-forth between business and engineering before a single story gets written. That’s where most enterprise rework actually starts.

An agent sitting across email, Teams, SharePoint, and the planning tool can take a BRD draft, surface gaps against the team’s standards, link it to existing systems and dependencies, flag missing acceptance criteria, and produce a structured first version for the PO and tech lead to review.

Not replacing the conversation. Just making sure the conversation doesn’t get lost.

The same data that makes brownfield, ops, and BRDs hard for humans is what makes them rich for agents.

What was harder than expected

Honest part: “Building the agent was the easy bit.”

The harder work was connecting context across tools cleanly and getting the guardrails right.

What should the agent only suggest?

What should it be allowed to create?

When should it ask for approval?

When should a human stay fully in control?

Everything stays human-in-the-loop — the agent drafts, suggests, and surfaces; humans approve before anything is created or changed.

That balance took longer to tune than the agent itself.

The bigger ambition: making team signals agent-ready

The bigger lesson:

Agentic AI does not start with a flashy demo.

It starts by turning real team activity into something clear enough to understand, classify, assign, track, and improve.

Once that structure exists, the harder questions get easier:

What keeps repeating?

What needs approval?

What can be automated?

What should stay with engineers?

What can be handed to an agent?

That is the foundation for coding agents, troubleshooting agents, self-service DevOps workflows, and eventually an agentic AI SDLC.

Where this goes next

The next step I am working on is bringing self-service DevOps workflows to developers.

Automated paths for the things that keep coming back as tickets:

Environment requests. Pipeline scaffolding. CI/CD setup. Security and compliance checks. Infrastructure provisioning. Common troubleshooting flows.

The idea is to eliminate a lot of this work at the source, before it ever becomes a ticket someone has to chase.

Vibe coding helps with the code.

It does not help with how the work even reaches the engineer.

That earlier layer is where I think real agentic AI begins.

Not another AI sandbox.

Not another chatbot demo.

This is the direction I’m exploring: turning daily team signals into structured work that agents can safely act on — with real tools, real workflows, and real governance.

Stay tuned — I’ll be sharing real insights from this journey as it evolves.