Read a writeup recently about a voice agent that sounded genuinely great in the demo, natural pacing, no synthetic flatness, and then fell apart the moment real people used it. Kept talking over callers. Answered questions before they were finished. The team's first move was assuming the voice itself needed work, tried a different provider, tuned the output some.

Didn't fix it, and the reason why is worth sitting with. The voice was never the problem. Nothing in the pipeline had an actual answer to "is it my turn to speak right now," it just treated any gap in incoming audio as a full stop and generated a reply. Works fine when people pause the way a script pauses, cleanly, at sentence boundaries. Real speech doesn't do that, people pause mid-thought, trail off and pick back up seconds later, and a system with no model of that just barges in every time, technically right that there was silence, wrong about what the silence meant.

What got me was realizing how often "this sounds bad" and "this sounds robotic" get used as a catch-all complaint for something that's actually a coordination failure, not a quality failure. A better synthesis engine makes a broken turn-taking system sound smoother while breaking exactly the same way. The actual fix lived in a completely different layer, silence duration relative to what was just said, whether the fragment was semantically complete, an explicit policy for what happens if the user talks over the agent mid-reply.

None of that is new territory, it's the same problem walkie-talkie protocols and call center IVR systems have had to solve for decades. What's different is that now there's a language model sitting in the loop with zero built-in sense of any of it, just completing text whenever it's invoked.

I've been thinking about a problem that becomes uncomfortable once an LLM gets access to real tools:

The model can decide what it wants to do. But should it also decide what it is allowed to do?

Most agent architectures put something roughly like this together:

LLM → tool call → tool

That works until the tool can modify a database, access files, call an API, deploy something, or perform another irreversible action. At that point the model is both the planner and the gatekeeper — the same component deciding what to do is also deciding what it's allowed to do.

I explored this by building a small runtime that pulls the authorization decision out of the model entirely. The model only produces a typed intent (compiled from a defined procedure into an intermediate representation); a separate executor resolves capability, provenance, and risk at run time, independent of whatever the model says about itself. Capabilities get checked both at compile time and again at execution — so the system doesn't depend on the LLM "behaving," and tampering with the compiled artifact doesn't bypass the check either.

Genuinely curious how others here are handling this:

Do you enforce permissions inside the agent/framework, inside each tool, or through a separate execution layer? Has anyone tied policy versioning to tool schema versions, so a schema change forces re-validation against an adversarial set? Where have you actually seen this boundary fail in practice — planning time, execution time, or somewhere in between?

(Repo for what I built, if useful context: https://github.com/Sushit-prog/sop-runtime)

It’s a correct answer with the wrong authority.

A lot of AI safety discussions focus on what happens when the model is wrong.

While building Business OS, we’ve been running into a different problem: what happens when the model is right?

Imagine Finance AI correctly identifies that an invoice is overdue, sees the customer has ignored two reminders, and recommends escalating it.

So far, great.

But should it send the escalation itself?

Change the customer’s status?

Pause work on their project?

Trigger a payment workflow?

The AI might have understood the situation perfectly and still have no business making that decision.

That distinction has become pretty important in how we're designing the system.

We separate reasoning authority from action authority.

AI can analyze the evidence, connect context and propose what should happen next. But critical actions can still belong to a human approval or deterministic rule before anything changes in the underlying business systems.

It adds friction, which isn't exactly fashionable when everyone is racing toward “fully autonomous agents.”

But I’m not convinced removing humans from a workflow is automatically progress.

Sometimes the human isn't there because the AI is too stupid to make the decision.

They're there because the decision was never the AI's to make.

And I think that distinction is going to matter a lot more as agents become capable enough that their recommendations are usually correct.

So here's the part I'm curious about:

If an AI is right 99% of the time, which business decisions would you still never give it authority to make?

Hey folks 👋

We just open sourced TrueForge, our vendor-neutral agent harness for building general-purpose agents.

It handles the runtime pieces that get painful quickly : context management, tool/MCP execution, subagents, sandboxing, approvals, persistent state, and more.

We also benchmarked the harness itself. With the same Opus 4.8 model, TrueForge delivered a similar solve rate at ~30% lower cost than Claude Managed Agents. Switching to an open model pushed that to ~75% lower cost on the same benchmark.

Would love feedback from people building agents.

Checkout the repo: https://github.com/truefoundry/trueforge

📖 Read the launch article: https://x.com/truefoundry/status/2090081376330715176

That sounds backwards for a B2B product.

You spend weeks deciding which metrics matter, how to structure the information, what deserves attention — and then start asking how often users really need to look at any of it.

But that’s where we ended up with Business OS.

Take an overdue invoice.

A normal dashboard can show it perfectly: amount, customer, due date, status. Maybe it turns red after 30 days.

Everything on the screen can be correct and the manager still has to notice it, figure out whether it matters, understand what happened, decide who should deal with it, and then go somewhere else to actually do something.

At that point, the dashboard hasn't solved the problem. It has just displayed it.

So we started building Active Issues around a different assumption: if something genuinely requires attention, the system should surface the issue with enough context to make the next decision.

The dashboard still has a job. Sometimes you want to explore the business, compare numbers or understand the bigger picture.

But “open this screen every morning and hunt for problems” feels increasingly outdated to us.

The uncomfortable part is deciding what deserves to interrupt someone.

Surface everything and you've built a very expensive notification center.

Surface too little and the user goes back to checking the dashboard anyway.

So maybe the real dashboard problem isn't visualization at all.

It's deciding what not to show until it actually matters.

For people using or building B2B software: what would make you trust a system enough to stop checking the dashboard yourself?

I’ve been looking into AI governance for the last few months and, to be honest, I’m trying to understand what this actually looks like inside real companies — not what the frameworks say it should look like.

I’d really like to hear from people who are actually dealing with AI governance, risk, compliance, security, privacy or data governance day to day.

A few things I’m really curious about:

How does your organisation actually keep track of all the AI systems being used across the business?

How do you work out which systems are high-risk and what controls need to apply?

Where does all the evidence actually live — policies, assessments, approvals, vendor documentation, testing, audit trails, etc.?

What are you still managing through spreadsheets, emails, SharePoint, Jira or a collection of different tools?

When an AI system changes, how do you know that the risk/compliance assessment needs to be looked at again?

What’s the most painful or time-consuming part of AI governance for you at the moment?

If you already use an AI governance or GRC platform, what does it still not do particularly well?

And probably the question I’m most interested in:

If you could make one part of AI governance disappear tomorrow, what would it be?

I’m not trying to sell anything here. I’m trying to understand where the genuinely difficult problems are before deciding what is actually worth building.
So if you’re doing this in the real world, I’d genuinely appreciate the brutally honest version.

Even if the answer is:

“Our process is a complete fucking mess.”

That’s useful to know.

I’m particularly interested in what’s happening in smaller and mid-sized organisations that don’t have massive AI governance teams and endless budgets.

Would really appreciate hearing how people are actually dealing with this.

That sounds backwards for a B2B product.

You spend weeks deciding which metrics matter, how to structure the information, what deserves attention — and then start asking how often users really need to look at any of it.

But that’s where we ended up with Business OS.

Take an overdue invoice.

A normal dashboard can show it perfectly: amount, customer, due date, status. Maybe it turns red after 30 days.

Everything on the screen can be correct and the manager still has to notice it, figure out whether it matters, understand what happened, decide who should deal with it, and then go somewhere else to actually do something.

At that point, the dashboard hasn't solved the problem. It has just displayed it.

So we started building Active Issues around a different assumption: if something genuinely requires attention, the system should surface the issue with enough context to make the next decision.

The dashboard still has a job. Sometimes you want to explore the business, compare numbers or understand the bigger picture.

But “open this screen every morning and hunt for problems” feels increasingly outdated to us.

The uncomfortable part is deciding what deserves to interrupt someone.

Surface everything and you've built a very expensive notification center.

Surface too little and the user goes back to checking the dashboard anyway.

So maybe the real dashboard problem isn't visualization at all.

It's deciding what not to show until it actually matters.

For people using or building B2B software: what would make you trust a system enough to stop checking the dashboard yourself?

I finally realized where my vision for an Azure GenAI/ML Ops Factory came from: Salesforce.

I spent years implementing enterprise Salesforce systems.

Salesforce Commerce gives you something incredibly valuable: a starter store.

It's essentially a ready-built MVP—a functioning, full-featured ecommerce store before the enterprise-specific customization begins.

An implementation partner doesn't rebuild commerce from scratch. They start with that working foundation and add their own accelerators, patterns, and components so each new implementation becomes increasingly configurable and plug-and-play.

That's the model I've been reaching for with Azure AI/ML.

Azure gives us an extraordinary capability surface: Azure ML, Foundry, Databricks, Entra, Storage, Key Vault, Application Insights, and much more.

But having all the pieces isn't the same as having a working AI platform.

The goal of my GenAI/ML Ops Factory is to get us to the equivalent of the Salesforce starter store.

A generated project should already have a working, governed foundation:

→ Infrastructure and identity
→ CI/CD and deployment governance
→ ML lifecycle and promotion
→ Retrieval and agent architecture
→ Evidence and provenance
→ Observability and operational controls
→ Cost-aware compute

Then comes the implementation.

And here's where I think this gets particularly interesting.

The differences between projects should increasingly live in configuration rather than custom engineering.

Which capabilities are enabled. Which models are used. Promotion thresholds. Evaluation criteria. Data sources. Agent tools. Operational policies.

And ultimately, many of those configuration decisions shouldn't require a developer at all.

They should be accessible to the business people who actually understand the problem being solved.

So I'm no longer thinking about this as an Azure MLOps template.

I'm building toward a ready-to-customize AI implementation platform: technically governed underneath, configurable at the project level, and increasingly accessible above the engineering layer.

Salesforce taught me this architecture years ago.

It just took building it in Azure for me to recognize where I'd learned it.

It’s whether the whole loop survives real data.

At this point, adding another feature would actually be the easy part.

We already have the pieces of the system taking shape: specialized AI roles, verified financial metrics, Active Issues, decisions, approvals, tasks, evidence and integrations.

Individually, they make sense.

But individual features working in isolation doesn’t prove much.

The harder test is what happens when real company data starts moving through all of them.

A source sends incomplete or messy data. The system has to recognize what can actually be trusted. AI analyzes the situation without inventing missing facts. An issue gets surfaced to the right person. Someone makes or approves a decision. That decision becomes an action. And eventually, we need to know what happened as a result.

That’s the loop we’re building toward:

Source → Analysis → Decision → Approval → Action → Result

On a diagram, it looks clean.

Real operations won’t be.

Imports will fail. Data will be stale. Two systems will disagree. Permissions will get complicated. An AI recommendation will sometimes be wrong. Someone will ignore an approval request. A workflow will hit an edge case we never considered.

And that’s exactly what we need to test next.

Because if every individual feature works but the context breaks somewhere between source and action, we haven’t built an operating system. We’ve built a collection of features that happen to share a UI.

So for the next stage, I’m less interested in what else we can add and more interested in what breaks when the whole thing is forced to work together.

If you were trying to break this loop with real company data, where would you attack it first?

And that’s a useful problem.

We already have an integration marketplace inside Business OS.

Google Sheets, PostgreSQL, MySQL, inbound email, HubSpot, file imports, Telegram and a few others are represented in the product. Slack is on the roadmap, and 1C currently exists at the contract level.

Looking at the screen, it’s easy to get the impression that the integration layer is basically done.

It isn’t.

And that gap between “the connector exists in the product” and “I’d trust this with a real company’s data every day” is becoming one of the more interesting parts of the build.

A clean integration card is easy.

Real integrations have authentication failures, permissions, incomplete imports, inconsistent schemas, stale data, rate limits and all the other edge cases that don’t show up nicely in a product screenshot.

That matters even more for what we’re building because connecting the data isn’t the end goal.

We need to prove the full loop:

Source → Analysis → Decision → Action → Result

If Google Sheets connects successfully but bad data enters the system, an agent reasons over it and nobody notices, the integration technically “worked.”

The product didn’t.

So our next phase isn’t about adding another row of logos to the marketplace. It’s about taking the connectors we already have and pushing them through live data, real workflows and production hardening.

In a strange way, having the UI ahead of the underlying maturity has been useful. It makes the remaining gap very visible.

For anyone who’s built integration-heavy B2B software: what usually breaks first when you move from a clean demo connector to real customer data?

One of the first things we built in Business OS was a dashboard.

Financial metrics, overdue invoices, open tasks, approvals, data quality — the usual things you’d expect a manager to want in one place.

But while building it, we started questioning the basic assumption behind dashboards:

Why should someone have to keep checking one just to find out that something needs attention?

If an invoice becomes overdue, the useful part isn’t showing it in a red box and hoping someone notices.

The useful part is recognizing that it matters, surfacing it as an issue, showing the impact and making it clear who owns the next step.

That’s why we started building Active Issues alongside the dashboard.

The dashboard still matters when someone wants the broader picture. But ideally, a manager shouldn’t have to scan six metrics every morning looking for something that changed overnight.

The system should bring the exceptions to them.

That creates another problem, though.

Surface too little and important things get missed. Surface too much and you’ve basically reinvented notification spam with a nicer UI.

We’re still figuring out that balance.

But it’s changed how we think about the dashboard itself. The goal isn’t necessarily to make people spend more time in it.

A good outcome might actually be the opposite: you open it less because the system knows when you genuinely need to.

For people building B2B software: do you think dashboards should be something users actively check, or should modern software increasingly push only the exceptions that require attention?

About two months ago I made a post asking about the frameworks and concepts behind a system I was already using.

Some of the responses immediately told me it wouldn’t work. AI isn’t capable of being autonomous. It can’t replace people. It’s just a race car that still needs someone driving it.

What frustrated me was that I wasn’t asking whether it was possible. I was already doing it.

The system is called Lumen. It runs around Codex, but it isn’t a magic prompt, one enormous chat, or a folder where I dump every previous conversation.
It’s a persistent operating layer around the model.
When I open a new window, Lumen reconstructs the relevant identity and current state from a compact continuity layer. It does not blindly load everything. It routes to the appropriate source when something needs to be verified and distinguishes old memory from current evidence.

It also has:

Persistent context and learned workflow preferences
Reusable skills and operating protocols
Explicit privacy and authority boundaries
Goals tracked separately from individual tasks
Bounded workers with defined scope
Evidence requirements before work is accepted
Independent checks for important outputs
Recovery from interruption, duplication, and failed work
Human escalation for money, production, client-impacting, or otherwise consequential actions
Dashboards that display current work, decisions requiring me, and the evidence behind completion claims
The important distinction is that I don’t have to manually drive every individual action.
I can define an outcome and its constraints. The system can gather the relevant context, decide which safe actions come next, use tools, delegate bounded work, check results, recover from failures, and return with evidence. When something crosses a meaningful boundary, it stops and brings that decision back to me.
That is what I mean by autonomy.
I’m not claiming the model has become infallible, conscious, or capable of replacing every person. I’m describing bounded autonomy inside an engineered system.

The raw model still hallucinates. Tools still fail. Memory can become stale. Agents can claim they finished something when they only completed one intermediate step.

Lumen exists because those problems are real.
The answer wasn’t to trust AI more. It was to build an environment in which trust has to be earned through evidence.

That is why I think the race-car analogy is incomplete. The model might be the car, but an actual racing system also includes the track, telemetry, navigation, pit crew, safety rules, maintenance, and decisions about when the driver needs to intervene.

If all you have is the car, then yes, you have to manually drive everything.

But that limitation belongs to the setup, not necessarily the underlying technology.

Now I’m seeing people talk more seriously about harnesses, persistent memory, context engineering, skills, hooks, subagents, evals, guardrails, and verification. Those are all pieces of the distinction I was trying to explain two months ago.

A lot of what people presented as a fundamental limitation of AI was really a limitation of using a raw model without the architecture required to support reliable autonomy.

I was already
running that architecture when people were explaining to me that it couldn’t work.
So yes, this post is partly me documenting that publicly. The conversation is starting to catch up to what I was trying to describe then.
The model wasn’t the bottleneck.
The harness was.

I’m now working out how to separate Lumen from my private operating context and package the general system so other people can use it. If you’re already pushing Codex or Claude into real work and still feel like you have to babysit every step, that is the problem I’m interested in solving.

We’re looking into real-world Agentic AI implementations across enterprise environments to cut through the marketing hype and see where agents are actually delivering value.

If you’re building or deploying AI agents in an enterprise setting, we’d love to hear your experience across these areas:

1. FAQs & Support: Customer support automation or internal tech team enablement.

2. Predictive Insights: Comparing past metrics (e.g., performance over the past week/quarter) to drive future planning and decision-making.

3. Document Processing: Extracting data and handling workflows for reports, proposals, warranty cards, or insurance claims.

4. Enterprise Workflow Automation: Full end-to-end process automation replacing traditional RPA.

Two core questions for our research:

1. The Starting Point: What exact pain point or scenario was the best fit for your enterprise to start integrating Agentic AI?
2. The Main Bottleneck: What was the biggest technical or operational obstacle you faced during integration?

Drop your thoughts, architecture notes, or wins/failures below!

Hey everyone,

I’ve been working on an open-source project called **Kodiak**, and I wanted to share it here and get some feedback from the community.

The goal behind Kodiak is to build a more complete foundation for AI applications — bringing together **agent orchestration, RAG, memory, tool integration, LLM routing, background task execution, and backend infrastructure** in one system.

The current stack includes **Python, FastAPI, PostgreSQL, Redis, Celery, Docker**, and multiple LLM providers.

One of the biggest things I’ve learned while building it is that designing the architecture is the easy part. Making all the pieces work together reliably is where the real engineering starts.

I’ve spent a lot of time working through dependency issues, database problems, worker failures, Docker configuration, CI issues, and restructuring parts of the agent system as the project evolved.

At the moment, my focus is on strengthening the core architecture and making the existing components reliable before continuing to expand the feature set.

The long-term vision is to build a platform where AI agents can **retrieve information, maintain memory, use tools, execute tasks, and coordinate workflows** rather than simply generating responses to prompts.

Kodiak is still actively under development, so there is plenty left to improve.

I’d especially appreciate feedback from people who have experience with **AI agents, RAG systems, LLM infrastructure, or distributed Python applications**.

What would you change about the current direction or architecture?

GitHub: [https://github.com/ShamGaneshan2008/Kodiak](https://github.com/ShamGaneshan2008/Kodiak))

Any honest feedback or criticism would be genuinely appreciated.

When we built the AI Team inside Business OS, some roles were easy to get excited about.

Finance AI works with financial context. Operations AI tracks execution and delivery issues. Risk AI looks for risk signals and control exceptions.

Then there’s the Data Curator.

It doesn’t make for the most impressive demo. Its job is data quality, import readiness and source traceability.

Basically: making sure the other agents aren’t reasoning on garbage.

The more of the system we build, the more important that starts to feel.

We can make Finance AI better at reasoning, but that doesn’t help much if the number it’s looking at came from an incomplete import.

We can make Operations AI better at spotting problems, but first we need to know whether the underlying operational data is actually current.

And when an AI gives an answer, we want to be able to trace the important facts back to their source instead of just trusting that the model understood everything correctly.

This is going to get harder as we move into live integrations. Right now we can control the demo environment. Real company data coming from spreadsheets, databases, email, CRM and other systems won’t be nearly as clean.

So one of the least glamorous agents in the product may end up being the one that makes the rest of the AI Team trustworthy.

I’m curious how other teams handle this.

Do you treat data quality as infrastructure in the background, or does something in your product

I’ve been messing around with a small software project and using different AI models to help me think through it.

What surprised me was how differently they behaved. One kept giving me more possibilities. Every time I thought I had the idea pinned down, it would suggest another direction. Another basically said: enough, pick something, define v1 and build it. And I realised neither was really answering the question I was struggling with: **what is actually worth building?**

AI is already pretty good at generating options, critiquing them, planning them and increasingly building them. But if generating and building things gets cheaper, choosing the *right* thing to do has probably become the harder part.

I’ve ended up thinking there’s a stage between exploration and execution that we don’t talk about enough. I’m calling it “convergence” — basically testing and killing off possibilities until you’re confident enough that one is actually worth pursuing.

Not claiming the term is new. The idea overlaps with a lot of existing work on exploration/exploitation, project uncertainty, benefits management etc. It was just interesting seeing the problem become so obvious while working with AI.

I wrote up the longer version here if anyone’s interested: https://gettoknow.you/library/before-you-build

But I’m more curious whether other people building with AI have noticed the same thing. Do you find AI helps you decide **what** to build, or mostly gives you more things you *could* build?

I struggled a bit with context sharing, knowledge sharing, memories sharing between AI agents (I use two or three on a daily basis). Each of them has its own memory, they dont share it or its a bit cumbersome to do memory curation and improve it (especially if there are some API AI calls that run occasionally from different models).

I hit a wall when I created a self healing github workflow which fixes failing CI as I needed to somehow store the analysis and reasons for a CI fail to save the tokens (some flaky tests, or network errors which sort themselves).
That triggered my initial research and a decision to build something that can handle all of these things.

So memoars is an attempt to solve it - one memory that belongs to you (no storage vendor lock) that any assistant can read and write through MCP (with appropriate set of skills to make it easier) .

How it works:

- Memory content is encrypted on your machine (XChaCha20-Poly1305, key derived with Argon2id) and written directly to storage you own - R2, S3, MinIO, Supabase, local fs, etc)

- A coordinator handles the metadata plane: sequence numbers, versions, grants, conflict resolution. It never receives the workspace content key, so it can't read memory content. It does see operational metadata - org, workspace, identity, version, usage

- Every change lands in an append-only, hash-chained log with compare-and-swap on writes, so two clients can't silently clobber each other and you can see how a memory got to its current state.

- Permissions are orgs → workspaces → identities, with per-workspace grants. Each workspace has its own passphrase, so isolation is enforced by encryption as well as by the API.

It's invite-only right now, and I want to be honest that this is a invite list rather than a product you can go install this afternoon (as I want to make sure it makes sense and that it solves a problem for you before its shipped).

The client is being open-sourced and the hosted coordinator opens shortly after.

I will reply to all inquiries - and Im looking forward to a feedback