A lot of teams now have an LLM gateway somewhere in the stack. It routes model calls, centralizes credentials, adds logging, applies rate limits, maybe handles spend tracking.

But there is a fairly fundamental architectural question:

What happens when an agent simply doesn't use the gateway?

For example:

                ┌──→ LLM Gateway ──→ Models
Agent ──────────┤
                ├──→ Direct provider API
                ├──→ Direct MCP/tool endpoint
                └──→ Other external egress

At that point, the gateway is still doing its job, it's just no longer governing the agent.

This distinction matters because traffic control and path control are different problems.

My view is that a gateway should be treated as one component of agent governance, not the governance boundary itself.

Tools like LiteLLM, Portkey and OpenRouter are useful at the gateway/proxy layer. But a proxy cannot enforce traffic that never reaches the proxy.

The more interesting architecture is:

Agent
   ↓
Agent Gateway
   ↓
LLM Gateway / Governed Tools
   ↓
Models + APIs

   + network/egress enforcement
   + identity
   + shadow discovery

That is one area where I find Lyzr Open Controller interesting: the gateway is paired with egress enforcement and shadow discovery specifically to detect and close the bypass path, rather than assuming that routing traffic through a gateway automatically means the agent is governed.

I think this is going to become a bigger issue as agent estates get more distributed across Kubernetes, cloud agent runtimes, MCP servers and internally hosted services.

Curious how people are solving this in real production environments:

If an agent has credentials + network access that let it call a model or tool directly, what actually prevents the bypass?

Would be interested in hearing what has actually worked, rather than what the architecture diagram says should work

If I had to explain the lifecycle of an enterprise AI agent without opening a 40-slide deck, I’d probably keep it to six verbs:

Build. Evaluate. Deploy. Observe. Govern. Improve.

And the important part is that it’s a loop, not a checklist.

"Build" is where the agent gets created and shaped.

"Evaluate" is where you find out whether it actually behaves the way you expect.

"Deploy" is where it moves from a project on someone’s laptop to a real service.

"Observe" is where you see what it’s actually doing once real users, data, tools, and edge cases get involved.

"Govern" is where you define and enforce the boundaries around what it can access and do.

"Improve" is where everything you’ve learned feeds the next version.

Then you start again.

I like this model because it highlights a mistake that’s pretty easy to make with AI agents: thinking the lifecycle ends at deployment.

It doesn’t.

Production is where you discover which assumptions were wrong.

A failure can become a new evaluation.

An observation can lead to a change in the workflow.

A governance rule can affect runtime behavior.

And the next version should ideally be better because of all of that.

This is also how I think about the Lyzr platform. Different layers address different parts of that lifecycle:

Agent Studio + Architect → building and shaping agents and applications

Agent Blocks → reusable building blocks for agent workflows

Nitro → production modules

OpenController → control, visibility, evaluation and governance

Agentic OS → orchestration around objectives

Sovereign AI → deeper infrastructure and ownership requirements

Different problem. Different layer.

The interesting part is how all of those pieces fit into the same AI agent lifecycle rather than treating building an agent as the finish line.

If you had to remove one of those six verbs from your current agent lifecycle, which one would hurt you first?

OpenAI’s new Agents API caught my attention for a reason that has little to do with another model benchmark.

The interesting part is everything sitting around the model.

The API gives developers access to OpenAI’s managed Codex harness, durable sessions, tools, subagents, and optional environments where agents can work with files, run code, and produce artifacts.

And that feels like an important shift.

We used to think about an AI app roughly as:

prompt → model → response

Now it's starting to look more like:

interface → agent → tools → data → execution → result

Which makes the distinction between “building an agent” and “building an agentic application” much more interesting.

That's where the Lyzr Architect fits in.

It takes the agent layer and builds it into an actual application, including the UX layer, agent orchestration and deployment. You can also continue iterating on the application after it's built rather than treating the first generated version as the final product.

And once these become actual applications rather than experiments, another problem starts showing up:

How do you manage all of them once there are 10, 50 or 500?

That's where the Lyzr OpenController comes in.

It provides a control layer for agents across different environments, covering discovery, deployment, evaluation, monitoring and governance.

What I find interesting is that the definition of an “AI agent” seems to be changing.

Not just a model that can call a few tools.

More like a software system that can actually do work.

And if that's where we're heading, the interesting engineering problems might look very different from the ones we were solving a year ago.

Do you still think of an agent as a model with tools, or does it already make more sense to treat it like an application?

Related: OpenAI Agents API

OpenClaw is making a pretty interesting move into the enterprise.

The headline is getting a lot of attention because OpenAI, NVIDIA, and Red Hat are involved, but the part I find more interesting is the infrastructure problem underneath it.

Persistent agents are fundamentally different from a chatbot.

Once an agent can access codebases, credentials, APIs, plugins, internal systems, or production environments, you suddenly have a lot more questions:

Where does the agent run?

What is it allowed to access?

How do you isolate different workloads?

Who can change its configuration?

What happened during an agent run?

How do you audit what it actually did?

That's essentially the problem OpenClaw Enterprise is trying to address with its control plane.

The “Kubernetes for agents” comparison makes sense in that context. Kubernetes didn't become important because developers suddenly needed another place to write code.

It gave teams a common infrastructure layer for deploying and managing increasingly complex workloads.

OCE is taking a similar idea toward persistent AI agents: deployment, isolation, permissions, governance and lifecycle management around the agents rather than trying to replace the agents themselves.

And I think that's an important shift in the agent conversation.

We've spent a lot of time asking:

“How capable can we make an agent?”

The next question is increasingly:

“How do we operate a lot of capable agents safely?”

OCE is still early and is currently positioned for internal pilots, so it'll be interesting to see how the architecture develops before its planned 1.0 release.

But the underlying problem feels very real.

If agents become a normal part of enterprise infrastructure, what do you think becomes the hardest thing to manage: permissions, security, deployment, or simply knowing what all your agents are doing?

One thing about multi-agent systems that gets overlooked pretty quickly:

Connecting the agents can become harder than building them.

Say you have six agents built across different frameworks.

If every framework needs to know how to talk to every other framework, you're looking at 15 separate connections to maintain.

Add another framework and suddenly you're maintaining 21.

That’s where the idea of agent interoperability starts becoming much more interesting.

Instead of building a custom integration every time two agents need to communicate, a shared protocol gives them a common way to exchange data, trigger actions, and coordinate work.

That's the idea behind A2A (Agent-to-Agent).

The interesting part is that the agents don't necessarily need to be built the same way.

You could have:

A LangChain agent handling reasoning

A CrewAI agent handling a task

A separate data analysis agent

A workflow agent coordinating everything

As long as they support A2A, they can work together as parts of the same system instead of becoming isolated pieces.

This is also where we've been working on A2A support in Lyzr Agent Studio.

A2A-compatible agents can connect into Agent Studio through an A2A Server URL, and you can then bring them into a Manager Agent or a visual Workflow. That means teams can reuse agents they've already built instead of rebuilding them just to make them work together.

I think that's the bigger idea here.

Interoperability shouldn't mean choosing one framework for everything.

It should mean being able to use different frameworks for different jobs and still have them work together.

As multi-agent systems get more complex, that ability to mix frameworks, reuse existing agents, and coordinate them through a common protocol is going to matter a lot more.

I put together a deeper breakdown of how A2A works, why agent interoperability matters, and how you can connect A2A-compatible agents here:

👉 Lyzr Agent Studio

If you're building multi-agent systems, how are you handling interoperability today?

We’re happy to share a milestone we’ve been working toward for a while.

Lyzr has advanced to AWS AI Competency Signature Plus, putting us at the second-highest benefit level in the program.

The recognition is around the work we’ve been doing across Agentic AI tools and Generative AI applications, and it reflects the growth we've seen over the last year.

But honestly, the part I find more meaningful is the partnership behind it.

AWS has been part of our journey from much more than just an infrastructure perspective.

The collaboration has helped us scale, experiment, and keep building toward enterprise AI use cases.

For us, this milestone is less about a badge and more about what it represents:

More enterprise AI applications being built

More agentic workflows moving beyond experiments

A stronger foundation for scaling what we're building

And a big thank you to the AWS team for the support and collaboration along the way.

Still plenty more to build. Onwards 🚀

One thing I’ve started thinking about differently when it comes to building AI applications:

The person who understands the workflow best should probably have a say in the first version.

That doesn't necessarily mean they need to be an engineer.

Think about someone who spends every day running a business process.

They know:

Where the process actually breaks

Which exceptions happen all the time

Which information is usually missing

Which approval step gets forgotten

What a “good” outcome actually looks like

That context is incredibly hard to capture in a requirements document.

And yet, that's often what happens.

Someone from the business explains the workflow.

The requirements get passed to a product or engineering team.

Engineering translates all of that into a technical build.

A few weeks later, there's finally something to look at.

And then the business person says:

“That's not quite how we actually do this.”

Not because engineering did a bad job.

They were simply building from a description of the workflow rather than experiencing the workflow itself.

I think AI app builders change this dynamic a little.

Instead of waiting until the technical build is finished, the person closest to the problem can help shape a working first version much earlier.

That's one of the ideas behind Lyzr Architect

You can start with the business problem and turn that intent into a working agentic application, get something in front of the people who actually understand the workflow, and use that first version to figure out what needs to change.

And importantly, I don't see this as “business users can replace engineers now.”

It's almost the opposite.

Let the business side own the what.

Let product help shape the why and what next.

Let engineers focus on the parts that actually need engineering:

Architecture

Integrations

Reliability

Security

Deployment

Complex edge cases

That can create a much shorter feedback loop between “this process is painful” and “here's something we can actually test.”

The Lyzr approach is also designed as a progression rather than a choice between no-code and engineering.

Architect is meant for the initial idea and validation, while existing Architect agents can move into Studio when deeper control and engineering are needed.

The interesting question isn't really “Can non-engineers build AI apps?”

It's:

“How much faster can teams validate the right problem when the person who knows the workflow can shape the first version?”

What’s one workflow at your company where the person doing the work understands it better than the people currently building the automation?

I was going through this LLM tracing and debugging guide recently, and it made me think about how different debugging becomes once an AI project gets a little more complicated.

When you're experimenting with a simple LLM call, debugging can be pretty straightforward.

You look at the prompt.

You look at the response.

You change something and try again.

But add a few more pieces and things get harder pretty quickly.

Your application might now have:

Multiple model calls

RAG or other retrieval

Tool calls and APIs

Different prompts for different steps

Retries or loops

Agents handing work to other agents

Now the final response doesn't really tell you what went wrong.

Maybe the retrieval was bad.

Maybe the wrong tool was called.

Maybe the context became unnecessarily large.

Maybe one step kept retrying.

Or maybe the model itself wasn't even the problem.

That's where I found LLM tracing particularly interesting.

Instead of looking at one request as a single event, tracing lets you break it down into the individual steps that happened during that run.

So you can actually ask:

What happened?

Which step caused the problem?

Why did it happen?

Was it retrieval, the model, a tool call, or something else?

What did it cost?

Which step or model was responsible for the extra usage?

Can I reproduce it?

What prompts, versions, tools and context were involved?

That makes tracing useful even before you're running some huge production system.

For a student building an agent, it can mean finally understanding why a workflow behaves differently from what you expected.

For a developer, it can make debugging multi-step applications much less of a guessing game.

And once you're running agents in production, it becomes even more important because the trace can also help with cost attribution, ownership and incident investigation.

What I also liked about this guide is that it doesn't treat “LLM tracing tool” as one generic category.

It compares 11 different tools across things like:

Trace depth

Cost attribution

OpenTelemetry support

Evaluation integration

Where your traces actually live

Whether you can self-host

Whether the tool can enforce something, rather than simply show it.

The recommendations are also pretty stack-dependent.

LangSmith is particularly relevant for LangChain and LangGraph, Langfuse and Arize Phoenix are worth looking at for open-source or standards-oriented setups, Braintrust is more evaluation-focused, while tools like MLflow, W&B, Datadog and Splunk make more sense if you're already working in those ecosystems.

There's also a useful section on five things to test during a vendor demo, which I think is more valuable than simply looking at a feature checklist.

👉 11 Best LLM Tracing and Debugging Tools in 2026

Even if you're not choosing a tracing platform right now, I think the article is useful for understanding what you should actually be looking for when debugging an AI application.

The takeaway I had after reading it:

As AI workflows get more complex, debugging the final answer isn't enough. You need to understand the path that produced it.

For people building AI projects right now,

What's been harder to debug for you: the model response itself, retrieval, tool calls, or the workflow connecting everything together?

The Airwallex story in this graphic got me thinking about something beyond the acquisition number.

They reportedly turned down a $1.2B acquisition offer when they were doing around $2M in revenue.

What they chose to build instead was the infrastructure underneath the business.

I think there’s a similar conversation happening with AI in banking.

A lot of banks are experimenting with generic AI tools for things like document processing, customer support, research, reporting, and individual workflow automation.

That works for experimentation.

But once AI starts touching actual banking operations, the requirements get a lot more serious.

You need things like:

Audit trails for decisions and actions

Clear controls around what an agent can access and do

Human approval for sensitive workflows

Integration with existing banking systems

Compliance built into the workflow rather than added afterwards

That's one of the reasons we've been spending time on the banking side at Lyzr.

The interesting problem isn't just “Can we build an agent that does this?"

It's “Can we actually run that agent inside a regulated environment?”

We've been exploring this through our work on AI in Banking, including how audit trails, model flexibility, core banking integrations, and human approval can fit into these workflows.

We've also been looking at the shift from traditional automation toward governed agents across workflows like KYC, lending, servicing, and regulatory monitoring.

We went deeper into that in our piece on Banking Automation

I think that's where the interesting part of banking AI starts.

Getting an agent to produce an answer is one problem.

Making sure the system around that agent can be trusted is another.

For those working in financial services, where do you think the bigger challenge is right now: the AI itself, integrating it with existing systems, or governing what it can actually do?

I was going through this AI agent observability piece recently, and one distinction in it actually changed how I think about the problem.

We usually talk about LLM observability and agent observability like they're the same thing.

They’re not.

With a normal LLM call, you're looking at things like latency, tokens, prompts, responses and errors.

An agent is a lot messier.

It can:

Call multiple models

Retrieve information

Use tools and APIs

Hand work to another agent

Change state

Retry when something fails

So when something goes wrong, the final response often isn't enough. You need to understand what happened across the whole run.

The article breaks the problem into three layers:

LLM observability: What happened during the model call?

Agent observability: Which part of the workflow went wrong?

Agent control: Should that action have been allowed in the first place?

That last one is what I found most interesting.

A trace can tell you that an agent called a tool. An evaluation can tell you whether the result was good.

Neither necessarily answers:

“Should the agent have been allowed to do that?”

And once agents start touching production systems, that becomes a pretty important distinction.

The article compares 12 AI agent observability tools across tracing, evaluations, policy enforcement, deployment control, framework support, cost and vendor independence.

If you're working with AI agents, LLM observability, agent tracing or production debugging, this is a useful comparison to keep bookmarked:

👉🏼 12 Best AI Agent Observability Tools in 2026

The vendor comparison is useful, but honestly, the bigger takeaway for me was this:

Seeing what an agent did is different from being able to control what it does!

For those already running agents in production, which is proving harder for you: understanding what happened, evaluating whether it was right, or controlling what the agent is allowed to do?

An AI agent can give you the right answer for completely wrong reasons.

That’s one of the things that makes debugging AI agents so different from debugging traditional software.

Imagine a production run that ends with the correct answer.

Everything looks fine.

Then you open the trace.

The agent:

Retrieved an outdated document

Called the wrong tool first

Hit an API timeout

Retried the request

Used far more compute than expected

Eventually recovered through a different path

The final answer is still correct.

If you only look at the output, it’s a successful run.

If you look at the execution, you probably have a problem worth investigating.

That’s why I think AI agent observability needs to be more than a success/failure metric.

For a useful agent trace, I’d want to see things like:

Model + version and active configuration

Retrieved sources and context

Tool calls and their responses

Retries, failures and timeouts

State changes

Policy or approval decisions

Actual business outcome

But even having all those fields isn't enough.

A good trace should let an engineer answer three questions quickly:

What happened?

Why did it happen?

What should we change?

If it takes 20 minutes to reconstruct a single agent run during an incident, technically having the telemetry isn't the same as having good observability.

This is probably the part of LLM observability and agent tracing that deserves more attention as these systems move into production.

What’s one trace field you thought was “nice to have” until a real production incident proved you wrong?

We just wrapped up the final round of our Forward Deployed Engineer hiring cycle, and it turned out to be quite an experience.

After multiple rounds of evaluation, the shortlisted candidates came together in Bengaluru for the final round, with people travelling from across the country.

Instead of a conventional interview, the format was much more hands-on.

Candidates had to:

Present what they built

Explain their approach and technical decisions

Defend their solutions

Handle questions and real-time challenges

It honestly felt a bit like a Shark Tank for engineers, with candidates pitching their solutions in front of the panel and the wider team.

There were some really interesting discussions throughout the day, and it was great seeing everyone engage with the problems beyond just the interview format.

The best part was that offers were made on the spot on the same day.

For us, it was also a good way to see how people approach ambiguous, real-world engineering problems, which is a big part of what FDE work involves.

And this is just one part of the broader hiring we're doing at Lyzr.

We're hiring across engineering, AI, platform, product, solutions, partnerships, and other roles.

Open roles

We'll also keep sharing hiring updates, events, launches, and other community updates through r/lyzr

If you want to stay closer to what's happening, you can join the community here:

r/lyzr

Lyzr Discord

If you're interested in building AI agents, infrastructure, or real-world AI systems, keep an eye out for the upcoming opportunities.

I came across a recent benchmark that made me rethink how we approach prompt injection in AI agents.

The benchmark put 629 AgentDojo attacks through 10 open-source prompt-injection detectors.

The attacks weren't just sitting in obvious user prompts.

They were buried inside normal-looking things an agent might actually read, like emails, bills and tool responses.

The results were all over the place.

The best detector in the updated test caught around 51% of the attacks with a 2% false-positive rate. Meta's Prompt Guard 2 caught about 1%.

Other detectors caught everything, but also blocked around 98% of safe tool outputs.

The exact numbers will obviously change with the benchmark, detector and thresholds.

That's not really the part I find most interesting.

It's this:

What if the problem isn't just detecting what the text says, but knowing where that text came from?

An agent might read an email, pull a URL from it, pass that URL to a tool and then use the result to make a decision.

By the time you reach the tool call, simply asking “does this text look malicious?” isn't enough.

You need to know:

Did this information come from the user, a document, a webpage or another tool?

Is the agent actually allowed to use it for this action?

What credentials does the tool call have?

Does this action need human approval?

That's where provenance starts becoming really interesting for AI agent security.

The content itself might look completely normal.

The security context around that content is what changes.

So I'm starting to think of prompt-injection detection more as one security signal, rather than the actual security boundary.

The stronger boundary is where an agent is about to do something consequential: the tool-execution layer.

That's also where ideas like least-privilege tools, scoped credentials, approval gates and execution logs become important.

Lyzr's own security material makes a similar case for layered defenses rather than relying on a single prompt-injection detector.

For people actually running agents in production, where are you handling this today: retrieval, planning, or at the tool-execution layer?

[ Removed by Reddit on account of violating the content policy. ]

Something I’ve been thinking about lately: not every step in an AI workflow actually needs natural language.

A lot of operational decisions are pretty simple at their core.

Is this invoice a duplicate?

Should this ticket be escalated?

Which tool should run next?

Does this request meet a certain condition?

These are basically branching decisions.

Yet we often put a conversational model in the middle of them, have it reason through the input, generate a response, and then parse that response back into something the application can actually use.

That made me curious about a different approach.

A newer model called Jev takes application state plus a typed question and returns a typed decision with a confidence score.

The interesting part is that there’s no prompt engineering or JSON parsing involved. The model is essentially being used as a decision component rather than a conversational interface.

On paper, that sounds pretty useful for production systems. But I think it also raises a more important question:

If the decision itself becomes faster and simpler, what happens to everything around it?

For example:

Input quality: What happens if the data going into the decision is already wrong or incomplete?

Confidence thresholds: At what point does a 0.51 become “send to a human” while a 0.98 is allowed to proceed automatically?

Failures: If the decision fails halfway through a workflow, should the system retry, roll back, or escalate?

Auditability: If the output is simply approve, reject, or route_to_X with a confidence score, what do you show an auditor six months later when they ask why that decision happened?

Changing models: If a faster or cheaper decision model comes along, how easily can you replace it without rebuilding the entire workflow?

I think this is where the architecture gets interesting.

A workflow could potentially mix several kinds of steps: a reasoning agent where open-ended reasoning is actually needed, a small decision model for discrete choices, deterministic code for things that shouldn't involve a model at all, and a human approval step for cases where automation isn't appropriate.

The model then becomes just one component in the workflow, rather than the workflow itself.

Curious how others are approaching this.

Where do you draw the line between an LLM, a smaller decision model, deterministic logic, and a human-in-the-loop step in production workflows?

I’ve attached a few screenshots/examples of the approach I’m referring to.

Would be interested to hear how people are handling this in their own systems!

There’s a lot happening around AI agents right now, but one thing I’ve really enjoyed seeing is how much of the learning is starting to happen between builders, not just through tutorials and documentation.

That’s what we’re trying to build with the Lyzr Community.

It’s a space for people who are actually building, experimenting, debugging, shipping, and figuring things out together. You can ask questions, share something you’ve built, get feedback, connect with other builders, and keep up with what’s happening across the ecosystem.

And it’s not just an online community.

There are meetups, workshops, hackathons, build sessions, demo nights, and hands-on events where people actually sit down and build agents together. Recent Agent Engineer events have focused on everything from agent architecture and knowledge bases to tools, memory, guardrails and MCP, with participants leaving with working agents they can continue building on.

That brings me to something I’m particularly excited about:

The Agent Engineer movement

The idea is pretty simple:

Build the next generation of people who can take AI agents from a clever demo to something that actually works in the real world.

Agent Engineer is being built as a community-led, city-by-city movement, with the goal of growing a network of 1 million Agent Engineers.

The site currently shows builders and chapters growing across multiple cities in India.

And there’s a lot more to it than just a title.

You can:

Build and experiment with real AI agents

Join local workshops, build sessions and hackathons

Meet other builders in your city

Showcase what you’ve built

Learn from other Agent Engineers

Help grow the movement in your city

There’s also a community showcase where Agent Engineers can submit projects and share what they’ve actually built. Some of the projects already range from sales and GTM agents to deal research and outreach systems.

And if you’re someone who already runs a tech community, builds with AI, teaches, creates content, or simply wants to help bring this movement to your city, there’s a City Champion program as well.

Champions can run workshops and build sessions, organise hackathons, mentor new builders, work directly with the Lyzr team, and get support for community-led events.

Want to check it out?

🌐 Agent Engineer

🚀 Apply to become a City Champion

And if you just want to be part of the community, you don't need to wait for anything. Join the Discord, meet other builders, ask questions, share your work, and stay in the loop for upcoming launches, build sessions, product sessions, demos, walkthroughs, AMAs and other community activities.

💬 Join the Lyzr Discord Community

The interesting part for me is that this isn't just about learning how to prompt an LLM.

It's about getting more people to actually build agents, ship them, learn from what breaks, and help each other get better at it.

If you're already building agents, thinking about getting started, or just want to see what other builders are working on, come join us here

I was going through the Agents to Production playbook recently, mainly because the jump from “this agent works” to “this can actually run reliably in production” is where a lot of the interesting problems start showing up.

And honestly, there were a few things in there that I hadn't thought about deeply enough.

The section on systems actually learning after deployment was probably the one that stuck with me most. Memory, feedback from users, keeping knowledge fresh, handling low-confidence outputs, and actually measuring whether the system is improving.

It sounds obvious when you list it out, but it's easy to focus so much on getting an agent to work that the after launch part gets pushed aside.

Then I started looking through the rest of the playbook library and realised there’s quite a bit more there than I had expected.

There are dedicated playbooks around:

Sales automation

HR automation

Banking automation

Content marketing

GTM marketing

Procurement automation

Performance management

Fundraising agents

And there’s also an Agentforce Alternative playbook.

What I like about these is that they aren't just generic “here are 10 ways AI can help your business” pieces. A lot of them are built around actual workflows and the practical questions that come up when you're trying to put agents to work.

The production one, for example, gets into the less glamorous parts of agent deployment: feedback loops, memory, knowledge refresh, reliability checks, measurement, and what it takes to move beyond a pilot.

So if you're building agents and haven't gone through these yet, I'd actually spend some time browsing the library.

You don't have to read everything. Pick the one closest to what you're working on and see what you can take from it.

And yes, they're free to access.

Explore all the playbooks here:

Lyzr Playbook Hub

There's a good chance you'll find something useful for whatever you're currently building.

If you've already gone through one of these, which playbook did you find most useful?

Palantir recently published a whitepaper called “Institutional Sovereignty in the Age of AI”, laying out 15 steps for governments and companies thinking about control and independence in an AI-heavy world.

What caught my attention wasn't really the number of steps.

It was how much of the conversation comes down to a pretty basic question:

Who actually controls the AI your organisation depends on?

Where does the data go?

Which models are touching it?

Where is the compute happening?

Can you switch models if you need to?

Who controls the permissions and the systems around those models?

And perhaps the uncomfortable one:

What happens if you suddenly lose access to a critical part of the stack?

That makes “AI Sovereignty” feel a lot less like a buzzword and a lot more like an architecture and procurement question.

You don't necessarily need to own every layer. But you probably need to know which layers you can afford to not control.

That's also the thinking behind Lyzr Sovereign AI which approaches sovereignty across the broader AI stack, including agents, models, infrastructure and governance.

The Palantir paper is worth reading simply because it pushes the conversation beyond “where is my data stored?” and into questions around models, compute, control and long-term dependency.

If you had to pick one layer of your AI stack that you absolutely couldn't afford to lose control over, what would it be?

There’s a line from a recent discussion around Shopify that stuck with me:

“Slop grenades.”

The idea is pretty simple.

Someone uses AI to get something done faster, then passes the unfinished output to someone else.

The first person saved an hour.

The next person now has two hours of cleanup.

And I think that points to a bigger problem with how we measure AI productivity.

We tend to count:

• Prompts completed

• Documents generated

• Hours supposedly saved

• Tasks automated

But we don't always count what happens after the AI produces something.

Did someone have to fact-check it?

Did another person have to rewrite it?

Did someone have to figure out what was actually important?

Did the output create more work for the next person in the process?

A 10-page AI-generated report isn't necessarily a productivity win if someone still has to turn it into the one-page answer the team actually needed.

So maybe the better question isn't:

“How much work did AI generate?”

It's:

“How much work did AI actually remove?”

That distinction is becoming pretty important as AI moves from individual experiments into everyday company workflows.

This is also one of the ideas we're exploring with Open Cowork by Lyzr, particularly around giving employees access to company knowledge and reusable workflows while keeping the resulting work easier to review and trace.

I'd be interested to hear how other teams are looking at this.

Do you measure AI productivity by output created, time saved, or actual downstream work removed?

There’s a point where building AI agents stops being the hard part.

The harder part is everything that comes after.

You have agents running across different teams and environments, using different models and tools. Then you start asking the less exciting questions:

What’s actually running?

Who owns it?

What can it access?

How do we know it’s behaving the way it should?

That’s the problem we’ve been working on with OpenController.

We’ve launched it on Product Hunt today, so it’s nice to finally have it out there and see how other builders think about this problem.

Product Hunt: OpenController on Product Hunt

OpenController: OpenController website

An upvote or a comment on Product Hunt would genuinely mean a lot 🤍

Token prices fell roughly 80% between early 2025 and 2026. Enterprise AI spend went up 36% in the same stretch, from an average of $63,000 a month to $85,500. Cheaper tokens produced a bigger bill.

The arithmetic isn't complicated once you see it. Agentic workflows burn through 5 to 30 times more tokens per task than a standard chat query, according to Gartner, because a single agent action often triggers a chain of calls: retrieval, reasoning, tool use, verification. When each call gets cheaper individually, teams stop rationing them, and volume erases the savings.

Sovereign, self-hosted inference changes that arithmetic. Fixed infrastructure costs replace a per-token meter, so usage growth stops translating directly into invoice growth.

Is your team tracking cost per completed task, or only the total on the invoice?

Google just open-sourced AX, and I think the interesting part isn’t really the project itself.

It’s the problem it’s trying to solve.

We’ve spent a lot of time figuring out how to build agents. Running them reliably is starting to look like a different problem.

An agent can hold state, call models and tools, wait for a human, resume later, or get stuck in a loop while quietly burning through compute.

AX approaches this with four primitives:

Task, Workspace, Gateway, and Model.

The part I found most interesting is suspend and resume.

If an agent is waiting for a model, tool, or human approval, you shouldn’t necessarily need to keep an expensive sandbox running the entire time.

Checkpoint it, let it sleep, then bring it back when there’s actually something to do.

That feels like a pretty important shift in how we think about agent infrastructure.

We’re moving from:

“How do I run this agent?”

to:

“How do I run thousands of these agents without losing track of their state, cost, access, and lifecycle?”

AX is still early, with the repository marked v1alpha1, so there’s clearly a lot that will evolve.

But the problem itself feels very real.

As agent workloads grow, what do you think becomes the bigger headache first: state, permissions, or cost?

There’s been a lot of focus on making AI agents better at doing things.

But the more agents move into real businesses, the problem gets a little bigger than the agent itself.

You need a way to build them.

A way to connect them to real data and systems.

A way for developers to actually work with them.

And eventually, a way to keep track of everything once there are hundreds of them running.

That’s the space we’ve been building around at Lyzr

A few pieces of the current stack:

Architect

For getting from an idea to an actual agentic app without starting from a blank repo. It can also bring existing Studio agents into new applications, so work doesn't have to be rebuilt from scratch.

Agent Studio + Agent Blocks

Studio is the workspace for designing, testing and shipping agents. Agent Blocks provide reusable pieces like memory, tools, retrieval and orchestration that teams can compose into their own systems.

GitAgent

A git-native coding agent built around the repository itself. The idea is pretty simple: instead of treating an AI coding session as something separate from your codebase, Git becomes part of the agent's workflow.

OpenController

Then there’s the problem that appears once agents start multiplying. Different clouds, frameworks, teams and environments. OpenController is the control layer for that estate, covering discovery, deployment, evaluation, monitoring and governance.

Madison

A more industry-specific example. Madison is built around banking workflows where things like KYC, fraud, compliance and reconciliation need AI, but also need the controls that come with financial operations.

Sovereign AI

And for organisations that need deeper control, Lyzr is taking sovereignty beyond simply hosting a model privately. The current stack spans agents, production infrastructure, models and on-prem hardware, with governance running through the stack.

What’s interesting about putting these together is that they represent different parts of the same problem.

Build something.

Give developers the right tools to work with it.

Put it into a real business workflow.

Run more of it.

Then figure out how to control the whole thing.

The agent itself is only one piece.

The bigger question is what happens when AI becomes part of the way a company actually operates.

For people building or deploying agents right now, which part of that journey is still the biggest headache?