No metric for performance, obviously. That would ruin the entire narrative.
How much CPU time an average request takes is probably the most important factor in the real world. No one running a frontier AI lab is going to honor any of the metadata described here.
This is a reductive framing of the problem. The power grid fuel mix is what determines most of this. There are some cases of on-site generation (which is definitely not ideal), but this can also be addressed with a better grid.
You can argue that the data centers shouldn't be built until the grid can catch up, which I think is probably the most defensible argument a Luddite could offer right now. I'd get on board with that one if it was presented rationally. However, it does appear that the environmental arguments are merely a means to and end for some. Quotes like this make it hard to not see the underlying goals.
Is there a problem with providing other metrics like water? I didn't see that mentioned any where in the article. Not to be snarky, but your response kind of reminds me of this famous tweet: https://x.com/AustingrahamZ1/status/1029385497213366279?lang...
If you want to talk about water you're obviously free to do so, but you were the one to bring it up. Most of the articles I see about water usage in data centers seems to be propaganda as well. That's not to say data centers aren't consuming more water. I'm sure they are. Considering however that agriculture still accounts for over 70% of overall water usage and we're wasting a lot of it growing things like alfalfa in water hungry regions. Last I'd seen the metric data centers were estimated at around 6%. So I'd argue we should probably look at the worst offenders first.
Bringing up alfalfa (which is horrible) is the typical whataboutism: wasting water there doesn't make it right to waste fresh water for basically cat pictures and slop.
Sprinkling it with dismissing the water issue with "propaganda" and calling agriculture "worst offenders" (seriously? Nourishment is bad and 6% for data centres is insignificant?)...
I don't think I can even remotely agree.
> A runtime environment must be developed to do that but where that of the agent ends and that of the enterprise systems begins is a totally open question.
I think something like SQL w/ row-level security might be the answer to the problem. You often want to constrain how the model can touch the data based upon current tool use or conversation context. Not just globally. If an agent provides a tenant id as a required parameter to a tool call, we can include this in that specific sql session and the server will guarantee all rules are followed accordingly. This works for pretty much anything. Not just tenant ids.
SQL can work as a bidirectional interface while also enforcing complex connection level policies. I would go out of band on a few things like CRUD around raw files on disk, but these are still synchronized with the sql store and constrained by what it will allow.
The safety of this is difficult to argue with compared to raw shell access. The hard part is normalizing the data and setting up adapters to load & extract as needed.
I'd consider storing (generating) them in AWS KMS. It's $1/key/month and you don't have to worry about hardware failures, etc. Each key must have a separate policy attached which controls who it can be used by and how. It is possible to create keys the root account cannot touch. If you have anything running on EC2, it's an extremely compelling option because you can authenticate directly via IMDSv2 tokens and IAM roles, avoiding the need for any kind of secret strings.
> My current expectation is that the Cowork/Codex set of "professional agents" for non-technical users will be one of the most important and fastest growing product categories of all time, so far.
I agree this is going to be big. I threw a prototype of a domain-specific agent into the proverbial hornets' nest recently and it has altered the narrative about what might be possible.
The part that makes this powerful is that the LLM is the ultimate UI/UX. You don't need to spend much time developing user interfaces and testing them against customers. Everyone understands the affordances around something that looks like iMessage or WhatsApp. UI/UX development is often the most expensive part of software engineering. Figuring out how to intercept, normalize and expose the domain data is where all of the magic happens. This part is usually trivial by comparison. If most of the business lives in SQL databases, your job is basically done for you. A tool to list the databases and another tool to execute queries against them. That's basically it.
I think there is an emerging B2B/SaaS market here. There are businesses that want bespoke AI tools and don't have the discipline to deploy them in-house. I don't know if it is ever possible for OAI & friends to develop a "hyper" agent that can produce good outcomes here automatically. There are often people problems that make connecting the data sources tricky. Having a human consultant come in and make a case for why they need access to everything is probably more persuasive and likely to succeed.
>UI/UX development is often the most expensive part of software engineering.
I disagree with this as a blanket statement. At least in the tech world (i.e. tech companies that build technology products), UI/UX is often less expensive than the platform and infrastructure parts of the technology products, certainly at any tech that runs at scale.
> There are businesses that want bespoke AI tools and don't have the discipline to deploy them in-house. I don't know if it is ever possible for OAI & friends to develop a "hyper" agent that can produce good outcomes here automatically. There are often people problems that make connecting the data sources tricky. Having a human consultant come in and make a case for why they need access to everything is probably more persuasive and likely to succeed.
Sort of agreed, though I wonder if ai-deployed software eats most use cases, and human consultants for integration/deployment are more for the more niche or hard to reach ones.
> The part that makes this powerful is that the LLM is the ultimate UI/UX.
I strongly doubt that. That’s like saying conversation is the ultimate way to convey information. But almost every human process has been changed to forms and structured reports. But we have decided that simple tools does not sell as well and we are trying to make workflow as complex as possible. LLM are more the ultimate tools to make things inefficient.
I'm having a hard time figuring out if I could use this as a replacement for something like AWS WorkMail or E365. The "Agentic" inbox looks really nice, but is this intended for humans to use? I am really confused due to the marketing hype.
The LLMs seem to struggle at anything that isn't relatively well anchored in whatever space. HTML documents have a lot of foundation to them in the training data, so they seem to perform well by comparison to other things.
I just spent a few hours trying to get GPT5.4 to write strict, git compatible patches and concluded this is a huge waste of time. It's a lot easier and more stable to do simple find/replace or overwrite the whole file each time. Same story in places like Unity or Blender. The ability to coordinate things in 3d is really bad still. You can get clean output using parametric scenes, but that's about it.
I think this is more of a case of the product getting worse incidentally. Contrast with leaders who are actually making things worse on purpose. Apparently, for no other reason than to be ugly and mean about it. I've been on this earth long enough to discover that monsters are real.
Windows 11 comes to mind as an example of something actually being made worse on purpose. Making it impossible to associate the original notepad.exe with text files is certainly not linked with business outcomes in any direct way. This seems to be purely about antagonizing the user base as much as possible. The only theory I can arrive at is that there is a secret cortisol harvesting scheme that results in better financial outcomes for Microsoft.
It helps to differentiate these cases. I don't like capitalism taken to the extreme, but the other thing is significantly worse. Intent makes all the difference. Engineered to suck vs sucks because it wasn't engineered are two completely different levels of evil.
> Oracle® Database Platform Guide 10g Release 2 (10.2) for Microsoft Windows Itanium (64-Bit)
Well, I guess that at least confirms Oracle on Itanium (!?) still supported RAW 5 years ago.
I'm guessing everyone's on ASM by now though, if they're still upgrading. I ran into a company not long ago with a huge oracle cluster that still employed physical database admins and logical database admins as separate roles...I would bet they're still paying millions for an out of date version of Oracle and using RAW.
Oh you're right! I was looking at the last documentation update timestamp, but the original release was 2006. That makes a lot more sense than Itanium support in 2021.
How much CPU time an average request takes is probably the most important factor in the real world. No one running a frontier AI lab is going to honor any of the metadata described here.
reply