bhaviav100

I have been in revenue operations for a decade.

For the last two weeks, I've started a personal 100-day challenge to study and build around what I've been calling a "Company Brain." I'm trying to understand what a company would need beyond search or RAG to actually make better decisions.

Most of what I see today approaches it as search, RAG, memory, or AI agents. I'm not convinced that's the right way to do it

If you've built something, researched it, or have strong opinions, I want to understand your thinking

This is great visibility..just checked the website..I will try this over weekend

Especially when you are running multiple agents for research

Sounds exciting..I liked the token counter concept. Didn't thought about it though. Do you have a GitHub repo?

I agree. This is huge market opportunity. I don't know whether anyone is building this

I haven't tried this .will do

If only there was a way to manage contexts better

Can you try this and let me know whether this helps you

https://authority.bhaviavelayudhan.com/

The only way to make something better is to use it more

Exactly why I built this.

But cost control is not an entirely policy problem. Policies are just guidelines.

This is interesting and I would love to understand more on this..is there a GitHub which I can look at?

Here's something which would help you with another perspective on the contexts https://authority.bhaviavelayudhan.com/journal/35

Both yes and no .we don't have a way to predict or forecast this

Companies won't survive with seats pricing

https://www.theoperatorscircle.com/journal/36

hmm interesting model routing + specialized MDs makes sense for cost efficiency.

I’m seeing a different failure mode though that even with good routing, agents are looping or retrying and burning my money.

yes, compaction and smaller models help on cost per step.

But my issue wasn’t just inefficiency, it was agents retrying when they shouldn’t.

I needed visibility + limits per agent/task, and the ability to cut it off, not just optimize it.

where is the link to Sarah?

DMed you. I would love to check this out

Sent you a DM

Interesting to see verification moving into the agent payment layer. are you seeing more risk from “incorrect execution” vs “unauthorized execution”. Feels like both problems are emerging at the same time as agents start touching money.

The separation between “agent reasoning” and “execution authority” is definitely becoming a real design pattern. what kinds of actions people are most afraid to let agents execute today. Is it mostly infra mutations, or business-facing actions like refunds/credits too?

This matches what I’ve been seeing too.

I’ve been building a similar enforcement layer, but focused first on customer-facing AI systems where mistakes create contractual or financial obligations rather than just infra damage.

One thing that surprised me in practice: teams don’t just need a state machine and allow/deny. They need the gateway to explain why an action was blocked, what policy path fired, and what approval chain would be required to proceed.

Otherwise ops teams can’t debug policy coverage when something goes wrong.

Curious whether you’re seeing demand more from infra teams or from CX / RevOps / compliance orgs right now.

I’ve been experimenting with exactly this pattern.

I built a small authority gateway that sits between agents and downstream systems and forces all high-risk actions through deterministic policy before execution.

In a v2 iteration I just shipped, the gateway returns:

• risk scores on attempted actions • the policy path that fired • highlighted spans in the agent output that triggered the rule • a preview of the approval chain required • admin endpoints to review and approve pending actions

The key thing I learned: teams don’t just need allow/deny. They need explainable enforcement so when something breaks they can see whether policy failed or the agent bypassed intent.

Curious whether people here treat message drafting and API execution differently, or if everything funnels through the same enforcement layer.

https://authority.bhaviavelayudhan.com/v2/console

I’ve been working on a small experimental gateway that sits between agents and customer-facing execution paths and forces decisions through policy + approval before anything irreversible happens.

v2 I just shipped adds:

• risk scoring on drafts • policy path traces • approval chain previews • highlighted spans showing what triggered the block • admin review endpoints

The motivation is exactly what people are pointing at here: once agents can transact, marketplaces end up banning them unless there’s a way to pause, inspect, and assign responsibility at execution time.

Curious what failure modes you’d want intercepted first if eBay or Amazon ever exposed agent purchase APIs.

https://authority.bhaviavelayudhan.com/v2/console

This isn’t about relative intelligence. Humans can be held accountable after the fact. Systems can’t. Once execution is automated, controls have to move from training and review to explicit enforcement points. Intelligence doesn’t change that requirement.

These are two different control problems.

Training governs what a model tends to say. Authority governs what is allowed to be acted on.

You can’t pre-block bad advice, but you can pre-block unapproved financial or contractual actions.

That’s the scope.

I don’t call it a failure of the AI. I agree it’s doing exactly what it was trained to do.

The failure is architectural: once AI is allowed to draft at scale, “don’t feed it commitments” stops being a reliable control. Those patterns exist everywhere in historical data and live context.

At that point the question isn’t training, it’s where you draw the enforcement boundary for irreversible outcomes.

That’s the layer I’m testing.

That’s true today, and it works as long as humans are the primary actors.

The break happens when AI drafts at scale. Training + sampling are after-the-fact controls. By the time a bad commitment is found, the customer expectation already exists.

This is just moving the boundary from social enforcement to a hard system boundary for irreversible actions.

Curious if you’ve seen teams hit that inflection point yet.

I’ve been working in RevOps for 10 years, and one pattern keeps showing up: accounts don’t churn because of usage issues first, they churn because the champion drifts away.

Champion drift is silent. No ticket. No alert. No one notices until renewal dies.

I wanted a small, code-first way to detect this earlier, so I built a tiny FastAPI service:

- You send a list of stakeholders, their roles, activity dates, and renewal date - The API returns a risk score (0 to 1), a risk level, and the reasons - It flags things like: * Champion hasn't been seen in 60 to 90 days * Champion left the company * Renewal is approaching without an active internal owner

Repository: https://github.com/malukutty/champion-drift-detector-api Interactive docs at /docs once you run it locally.

This is not a product. Just a minimal piece of logic that I think should exist in the world. If you have ideas to make the scoring smarter or want to extend it, I’d love feedback.