Claude Opus 5 is live, with a million tokens of room
Anthropic released Claude Opus 5, their new flagship. It's in Aisle already, in the model picker for chats and everywhere else you choose a model. Nothing to set up, nothing to opt into.
We've also demoted the Opus 4.x models. They still run, and anything you've pinned to them keeps working. They've just moved down the list, and Aisle will nudge you toward Opus 5 when you're picking fresh.
Our advice is the same as at every launch: don't rip out something that works because a higher version number shipped. Take your real prompts into Playgrounds, run them side by side, compare outputs, and switch when the comparison tells you to.
Your shared chats aren't in Google
Thousands of shared Claude conversations turned up in Google results this week. Medical reports with patient names, legal questions, client documents, crypto keys, and a set of files with primary-school children's phone numbers in them. The crawl pulled in artifacts alongside the chats. Nobody hacked anything: people pressed share, the links were ordinary public web pages, and search engines indexed them the way they index any public HTML page.
Anthropic described a design rather than a fix: the links aren't guessable, they don't hand sitemaps to Google, sharing a conversation makes it public, and each of those is true. None of them tells a crawler to skip the page. Google Docs share links work almost identically and don't show up in search, because that one instruction is there.
Aisle public links are read-only, and you can revoke one at any time by switching the link off. Prompts and resources stay scoped to your organization, and nobody outside it can see them.
Coverage: TNW · Axios · Futurism · Search Engine Journal
Cobalt
Cobalt by FactSet, the portfolio monitoring platform for private capital, is now available on Aisle.
Connect your credentials under Settings > Integrations and Cobalt shows up in the task editor like any other connector.
CobaltNew
Private capital portfolio monitoring, by FactSet.
The editor got a UX overhaul
When you open a Task this week it will look different. Rather than list every change and have you match bullet points to buttons, Mitch recorded a walkthrough of the new editor.
A quick tour of the recent UX changes in the Aisle Tasks editor.
Two additional upgrades to the AI task editor:
- Full lifecycle support. The builder could already create and edit inline prompts; now it can remove them too, so you can create, edit, and remove prompts from one place. It won't delete a prompt that a script in your task still references, so you can sweep away an abandoned experiment without taking a working step with it.
- Testing Postgres connections. The builder can now check a Postgres connection by actually querying it, inside a read-only transaction. Reads go through and destructive operations fail, so you find out whether the credentials work without finding out what happens when they work too well.
Both are live in the task editor now. Nothing you've already built changes.
Two posts on doing less with the model
How to cut your token consumption 50x: Moving an automation off agentic reasoning and onto a deterministic Python task cut token use by up to 50x, with no loss in what the automation actually does. Most steps never needed a model in the first place.
The not-AI part: Building a six-phase competitive intelligence Task with the AI Task Builder made one thing obvious: the model is the smallest part of the work, and the plumbing around it is where the reliability comes from.
For the developers on this list: how to set up feature and spec memories in Claude Code that survive across sessions and carry across everyone on your team, instead of re-explaining the same architecture every morning.
Memories that persist across users and across sessions.
Video transcript, 1 of 2
Hey guys, Mitch here from Aisle. We've recently made a couple of UX changes to the tasks editor, and so I thought I'd take this opportunity to spend a couple of minutes showing you some of those changes and giving you a bit of a general overview of the anatomy of a task on Aisle. And we'll do that by building a really simple task along the way. So, we're going to start here. This is the new task screen, and you'll see there is this main panel here in the middle, and then there is this right-hand toolbar.
And what we're going to do is we're going to build a quick task that fetches a meeting summary from Fathom, which is a meeting recording tool, and then composes like a small tweet that summarizes that meeting. And we're going to do that by using the AI builder. First, we're going to come over here on the right, and we're going to go to tools. This is a part of the settings that allows you to manage which integrations are able to be called by this task. So, we're going to search for Fathom.
You can see here I have a couple of different credentials. I'm going to select this one, and now this task container has the ability to fetch calls from Fathom that are mapped to these credentials and these credentials only. You can come back out of here, and in the package, you'll see there's an overview, and there's the actual task script itself. Keep an eye on this package. This is where any inline prompts that we create, or any other artifacts that are part of the script, end up in this package here.
Next, I'm going to go and enable the AI builder. From the overview screen, I can click it here, or you can always click this button in the top right. Iterate with AI. That's going to open up this builder mode where I'm going to describe what I would like. I would like to fetch a meeting summary from Fathom by giving a meeting name as an input, and I would like to compose a short overview of meeting max 280 characters.
Great. And you can see here that in this first turn, it has gone ahead and created a new inline prompt called meeting overview. It is defined an input. It has changed the setting, so it's given it a name and a description for the entire automation. And it is also written the task code in Python.
We can accept these changes. Nothing else to accept here in the history. We can leave AI mode. You can see here that the script has updated and the package has updated to have a new inline prompt. You can view that inline prompt separately.
We could come in here and make some manual changes. We could change the model. So, we could say that this should be Opus 5, or this should be GPT, or this should be Gemini, or this should be Grok, or any of the models that are available on the platform. We could add other capabilities to this prompt, web fetch, web search, if we wanted to. You can see here at the top as well that the inputs have been defined.
You can add inputs through this screen here. This takes you to the setting screen, so you can see here that the meeting name text input has been defined. It has a description, has a default value, we've set it as required. There are a number of different things here that can be configured to be input types. And the setting screen is also where you would update or set the trigger type.
So, right now it is a manual or on-demand trigger. You can change that to something that runs on a schedule. You can change that to be a webhook coming off one of our supported integrations. You can change that to just be API. We support a number of different trigger types.
And then there are some advanced settings here. For most automations, the expected run time would be under 15 minutes, but we do support long-running automations as well. You would toggle over here. You can also limit concurrent runs, and you You set how many max retries and what is the backoff between those retries. Coming out of the settings, back to the overview, the only other thing to show you that has changed in the UX is you can click down the bottom here, SDK reference, and pull up the entire Aisle SDK and search for what we want.
So, if we wanted to add a checkpoint, you can see here is Aisle checkpoint, and you can look at all of the different ways that we can add checkpoints. So, that's a brief overview of the changes to the UX for Aisle tasks. Thanks.
Video transcript, 2 of 2
Hi, I'm Alex Andervile and today I'm going to take you through something a little bit different, which is how we and our development team use the memories feature to create persistent memories in Claude Code Code X and the other things we're using in our development process. Now, a lot of development teams we speak to are starting to run into this. They've been transforming their SDLC processes. They've gone from maybe using basic LLMs to treating AI more seriously in the development process. And you start to run into where you're going to store a lot of stuff.
And what I mean by that is we still have documentation for features and that belongs in the repo. But once we're using agents more seriously, we start keeping track of the decisions that have been made and harnessing them better. And where do we put that? At some point you end up with hundreds of different markdowns in the repo that you have to maintain and don't make sense. One of the other things we like to do is keep track of all the bugs that have been resolved so that we can look at them, see what's common, maybe we need to change the process or scan through them every week.
So, to jump straight in, what I'm going to do is I have Aisle open here and I'm going to go to memories. I'm just going to create a new folder here. We could call this, you know, development documentation, for example. And it's up to you. I'm going to turn on searchable by AI because I prefer a vector search to get some deeper results.
Once this folder has been created, all we need to do is press settings here. And if you didn't know, any memories folder you can actually create an external MCP that you can use in other tools, Claude Code, Cursor, Claude, ChatGPT, it doesn't matter. So, I'm going to press add a connection here. You can actually create several. And I won't scroll all the way down.
Uh it's okay, we'll just delete this later. Uh so that you can basically copy-paste this into your settings. You'll see there instructions for different tools here and how that you would deal with adding it. Once this memory server has been added, it's really easy. I'm actually just going to toggle over now to a terminal window that we have lined up in a demo environment with Claude Code.
And this is just thinking about our task SDK and maybe trying to add some better date stuff. So, I'm going to see, you know, let's add this, you know, little feature here and press enter. And now that this memory server's been added, and obviously there's a little bit of system prompting involved, it's actually going to go through and search that IO memories folder first to see if there's any relevant documentation that's going to help it solve that feature. One of the things we do is we actually allow agents to write to these folders, to write updates. And if you've seen any of our memory videos before, you'll note any changed to memories versions.
So, you can go back and see what's been changing over time. Now, to perhaps help you visualize as this is running, I'm going to click back and show you some of these folders. So, this is actually hooked up. This is all demo data here to an IO features demo folder that has some, you know, basically spoofed documentation about our features and what we'd be having the agents track. So, you can see we have this basic, you know, agent-written documentation here in terms of what is the task SDK, you know, what is it, how does it work, and what are some references.
Uh, I can't explain to you how useful this has been through the development process to have agents basically be allowed to self-document things that they find interesting and then be able to search it themselves later across different code sessions, across different developers. And it kind of becomes this self-documenting engine. Uh, the honest answer is there's probably 10% of crap in here that we don't need, but it's much better to have all of this than to not as we're having agents go through and re-solve the same problems uh quite repeatedly. And you just don't have time to prompt through everything correctly. To give you another example, we often go through and have an agent, you know, at the end of a feature write a blog.
And I like to have a little bit of fun and tune it to roast me at the end. What did I do well? What didn't I do well? If you're laughing about me, what would you say? And it starts to write these really nice reflective blogs in terms of, you know, what did I do?
What made this task harder than it looked? What did we do that we're not proud of? And how did the code base screw you up? And the amount of times that I've gone through these blogs and I've then just started another session saying, "Why don't we fix this properly?" has been an incredibly useful reflective loop while keeping the agent that I care about on target. So, it's a very short video here, but hopefully what you're following is that you can come here, create a bunch of memory folders, use them to store things like feature documentation that an agent is going to self-document as it's working on a feature over here, uh any bugs that it's finding, uh even, you know, things like the roasting blog, and it lets you start to build an agent that has persistent memory across developer sessions, and it even doesn't matter if you start moving from Claude Code to Codex.
And you might be thinking, "Why don't we put all this in the repo? Docs belong in the repo." The answer is our main line docs do go into the repo, but we don't want two to 300 markdown documents of agents that have reasoned through features, but keeping and persisting that decision log and what we did on the way has really started to reward us over the last period. So, thank you for watching. As always, we're around. Uh reach out for any support.
Give us any feedback, and we'll talk soon.