_pdp_

Part of the threat model. If that is an issue then don't add the capability to the agent. It is simple as that. But we cannot guarantee that the agent wont leak some information. So if you connect personal accounts (i.e. oauth) this information can be guarded with technical controls that sit outside of the agent. If the agent is authenticated with shared credentials then you have to add instructions and other soft guardrails but ultimately you should assume that everyone has access to the information.

I don't think there is any dispute there is a real risk. But hype does not really help shape the conversation and this is the problem. I am sure both companies know more than they can disclose and that gives them unique perspective outsider don't have but let's face it, both are also financially incentive to act as they do. I am not going to get into the conspiracy theories but one does not need a lot of imagination to figure out how this could pan out. Either way, it does not help the conversation that needs to be had and it is urgent. It is certainly not helping at all given that same capabilities exist in open-weight models.

I am not saying it is marketing but typically when there is a data breach you may hear from the CISO but most of the time is is vague PR response. In this case I get loud signals from both HG and OpenAI leadership without much information exactly what the attack was about just that GPT x.x was involved. It is unusual all I am trying to say.

Perhaps you are right. We've only been using them for two weeks.

Hang on a second. You think accessing private information in a public channel is a good idea?

If a tool is authenticated as personal then it can be only accessed under personal context - i.e. privately. Now if the author of the agent wants to add tools authenticated with shared secrets that is something should be considered in the threat model.

In other words:

- reading my personal emails in a public setting - not ok - reading the agents shared inbox in a public setting - probably ok depending on the threat model

We've tried them. So far quite expensive with not much return. This channel might not work as well as search.

No channel will disclose private information. The only way to get that to work is to DM the agent directly or to use slash commands which are ephemeral / private.

It is safe bet to assume that all of them are generated with LLMs.

I agree with what you are saying but this is not how we solved the issue with who can access what.

In our cloud harness we have the notion of shared and private secrets. When something is authenticated with a shared secret it is basically something that can be used in a public setting. If something is private then it can be only accessed via trusted channel. It works for slack, telegram, etc.

In fact, our slack agents are very strong this department and it is guaranteed there is zero leak of private information.

I am not sure. I think of myself as a pro user yet I am finding hard time maxing out Pro tier. It only happens with sub-agents without any material returns.

The reason most people burn through their allocated limits is mostly because of sub-agents. Stop using them and you will find out that even the Pro tier is enough for daily 8-12h coding sessions. Don't use Fable though.

True. It cuts both ways. :)

I am impartial on the matter, but I think one of the reasons Bun became a thing in the first place was because of Zig attracted a small but very active developer community. Switching from Zig to Rust effectively alienates that community.

20 years ago we used to pay a lot for things that are now practically free. I don't think AI is an exception.

IMHO these type of projects are not tools per-se but methodologies. I think this is a better framing since that's exactly what they are - a bunch of markdown files that describe in general terms how to perform an assessment aligned to some principles.

Btw, these type of methodologies are used all the time. Practically every security consultancy has them so adding them to an LLM makes a lot of sense.

We don't know what we don't know but it does not look like that complex. We have not hit any edge-cases yet. I am sure there are some.

You can scale firecracker vms like really fast. In our shop we have a simple go service that maintain the state in a sqlite database. The only requirement is bare-metal servers.

https://chatbotkit.com/reflections/what-it-really-takes-to-b...

I had to deal with exactly this issue with one of my recent oss projects so I can share a few things on the topic.

1. Text is the default interface

i.e. the api must be text based first but it should allow to fallback to structured output by using the accept header.

That being said, it is not wrong to introduce other means to return json by using ?format=json etc.

2. Make it grepable

Basically surface as much useful information in a single line so that the agent can grep and slice.

3. Identifiers must be short

i.e. short enough to describe in 5 tokens but not too short to introduce collisions or confusion.

Otherwise you could be wasting a lot of token for nothing. However, adding prefixes helps like cus_abc123, token_xxx, etc. The prefix can help with lookup, error correction and deduplication.

4. Surface information that is likely to be used by the agent

i.e. if the agent is asking for a list of resources, don't just return the list but also some additional information that might help the agent understand better the context around the resource.

Without this a single task could take a lot more steps simply because the agent needs to run its own loop - it is slow and expensive.

5. Add bulk operations

It is a lot easier to insert 10 records in one request then performing 10 separate requests.

6. Error messages should be descriptive

Ensure that error message point to actual docs and manuals that can be read by the agent so that it can troubleshoot on its own. Also return hints.

I've added most of these at https://github.com/crmkit/crmkit which is highly experimental CRM I tried to specifically design for AI agents. We use it internally for a few projects and it is not perfect but I think it might be on the right direction.

I hope this helps.

It is a fashion thing. I am not saying that agentic TUIs are bad or anything but it is certain fashionable to use one in 2026.

You will be surprised how much code goes into creating harnesses.

I thought it was a new model.

Vibe-coded software require a new type of discipline that has not been invented yet.

Every company I have seen implements more or less the exact same stack, with a few small variations. The problem is that it is often not very good and is usually months, if not years, behind. I have already seen this in several places, including a few F250 companies.

Frankly, it is a waste of time. It is expensive to build, expensive to maintain going forward, and often already dated by the time it is finished because things have moved on.

Also, as much as I like code, and would personally prefer to build things in code, a lot of internal innovation happens because end users have access to agentic tools. Yet, from the outset, both OpenAI and Anthropic FDE approaches seem heavily code-driven. I might be mistaken.

In my opinion, it is much better to deploy a more customisable harness that sits across the different technology stacks that is also user-friendly. But then I am biased, because that is what we do, so take this comment as you will.

Well I think it is the platform layer. If you can blow up $1m on a harness sure… otherwise rent it.

It is cool to see not sure why you would use it.

Also it seems to me that this is a good way to exfiltrate data, rubber stamped by cloudflare themselves.

I've been waiting for this for a long long time. Congrats on the release.

Fable is better than Opus and I do not think there is much argument there. And yes, it is natural to get used to a new tool and even end up liking it more over time. What I am trying to say is that it does not feel like the step change they are claiming it to be.

I fully agree with your point about Taleb. And yes, it can come across as a bit glib, but the underlying point is not new. Do not judge a book by its cover. That idea exists across many cultures, fables, and stories, so it holds IMHO.

The surgeon example is just an illustration of that idea, and it is a great example because it makes the point memorable. In practice, of course, I agree that most modern surgeons are trained to broadly similar standards and look and act the same, with some outliers and historical exceptions.

When I said "running it yourself" I didn't mean me personally running it at home. That will be unfeasible. A company can afford it though and also a supplier that serves multiple customers can do that as well. In fact, I was talking to a company that does this and the model is fully in UK where we need them to be.

At the end of the day it is about the sense of optionality. We know that this is the business model for almost all open source projects. It is not like you cannot download and run the project yourself and some do for practical reasons, but often times the cloud version is priced such that it is the path of least resistance so people go for that.

I couldn't find a situation where Fable was significantly outperforming Opus enough to make me say wow.

I tried to make it fix a browser game that is sort of like a Mario clone. It couldn't. It fumbled in the same places Opus was struggling too. I tried it with other code as well, but I couldn't get any significant performance improvement out of it, except perhaps in improving my account's token burn.

If anything, in my opinion, GLM 5.2 had a better moment than Fable recently. Not because it is better, but because it was not hyped at all, and many people realised that it is possible to run a serious open-weight model yourself, as long as you can get the hardware to support it.

I am not drawing a direct comparison here, because Fable is clearly the better LLM. But GLM 5.2 is a good, honest model, and I think open-weight models will only get better going forward.

GPT 5.6 is claimed to be at a similar level, or even better than Fable. We will see. They don't seem to hype it as much, and I have not read anywhere that anyone found a soul or consciousness inside it. And if it benchmarks well, I would possibly use it more for this very reason.

It reminds me of that story from Nassim Taleb's Incerto series where if you have two surgeons at practically the same level, but one looks like the typical surgeon and the other looks like a butcher, who are you going to choose? Taleb suggests that the answer should probably be the butcher, because to get to the same level while looking the part so much less, they probably had to be much better than the data shows for.

I cannot also understand the hype online claiming that the Fable transitioning to token-based billing after the gratis period is equivalent of being in the permanent underclass. The only impressive demo that I saw was it writing NES games which kind of looked fun but I couldn't find more details and I am not sure if you can get this done with another model - probably you can but nobody is trying.

So great model but it does not have the same effect as Opus 4.5 and Codex which made me feel that there was a stepping-stone change.

GLM 5.2 had that moment though.