That figure needs considerable context. Humanity has never built a superintelligent AI, so there is no historical evidence from which anyone can reliably calculate such a probability. Professor Kate Devlin of King's College London points out that predictions of human-level or superhuman AI being only a few years away have been made before, and nobody actually knows whether today's technology will ultimately lead there.

But uncertainty doesn't necessarily make the issue irrelevant. When the possible consequences are sufficiently severe, even a small and uncertain probability can justify precautions. The problem with AI is that we're being asked to make those judgements while the technology itself is changing extremely quickly.

The popular version of an AI catastrophe usually involves machines becoming conscious and turning against humans. Most serious AI safety research is considerably less cinematic.

AI also doesn't necessarily need to be deliberately misused. As we move from chatbots that provide answers towards AI agents that can access browsers, files, software and other systems, mistakes become more consequential. An incorrect chatbot response can be ignored; an autonomous system acting on an incorrect assumption may be able to make changes before a human intervenes.

The most extreme scenario is a future AI sufficiently capable and autonomous that humans struggle to control it. Today's systems aren't capable of this, something the International AI Safety Report makes clear. What interests researchers is whether some of the capabilities that might eventually contribute to such a scenario are beginning to emerge.

The UK's AI Security Institute tests frontier AI models against tasks associated with autonomy, cyber security and other potentially dangerous capabilities.

As Professor Kate Devlin argues, we don't currently have superintelligence and nobody knows when, or even whether, it will arrive. Today's systems remain unreliable in surprisingly basic ways, and there is no guarantee that making current models larger will eventually create something vastly more intelligent than humans.

Perhaps the strongest reason for taking AI safety seriously is the incentive structure surrounding its development.

OpenAI, Anthropic, Google, Meta and others are competing for customers, investment, computing power and technical talent. Governments increasingly regard AI leadership as strategically important too.

That makes slowing down difficult. If one company delays a new system because it believes further safety research is required, a competitor may continue. The same problem exists between countries. Cautious development might benefit everyone collectively while rapid development remains the rational choice for each individual participant.

That distinction matters. We already accept that potentially transformative technologies can require significant restrictions without abandoning them. Pharmaceuticals undergo clinical trials, aircraft require certification and nuclear technology is subject to extensive controls. AI is different from all of those technologies, but the principle that greater potential consequences justify greater scrutiny isn't particularly radical.

The 2026 International AI Safety Report reflects this uncertainty rather well. Its contributors don't agree on the probability of humanity losing control of future AI systems and the report doesn't predict that such an outcome will happen. It does, however, recognise that the possible consequences are serious enough to justify research and preparation.

The fact that King Charles is now bringing some of the industry's biggest names together to discuss the future of AI is another indication of how far this discussion has moved beyond technology companies and research laboratories.

It is tempting to start by creating fields, adding modules and building workflows. Before configuring anything, though, the business needs to understand what the CRM is supposed to support.

That means establishing how an enquiry becomes a customer, what information needs to be collected, who is responsible at each stage and what should happen next. It also means identifying exceptions, handovers and processes that currently depend on somebody remembering to do something.

Our strongest implementations have always started with discovery. Once the underlying process is understood, Zoho CRM can be designed around it. Without that work, businesses risk recreating their existing problems in a new system.

A CRM can be technically correct and still fail if it is inconvenient to use.

When users have to search through long layouts, complete irrelevant fields or perform unnecessary steps, they begin finding ways around the system. Information is entered inconsistently, notes are stored elsewhere and important updates are delayed.

Successful CRM design therefore needs to consider the everyday experience of the people using it. Clear layouts, sensible field names, helpful descriptions and well-designed views can make a significant difference.

The objective is not simply to capture more information. It is to make the correct action the easiest action.

Automation is often one of the main reasons a business invests in Zoho CRM. Workflows, blueprints, scheduled functions and integrations can remove repetitive administration and help ensure that important actions are not missed.

However, automating an unclear or inconsistent process usually makes the problem harder to correct. Before building an automation, the trigger, required information, responsible person and expected outcome all need to be understood.

We generally prioritise automations that have a clear operational benefit, such as:

The most valuable automations are often not the most complicated. They are the ones that remove a frequent manual task or prevent a costly omission.

Moving data into Zoho CRM is not simply a matter of uploading a spreadsheet. Existing data often contains duplicates, inconsistent formatting, incomplete records and values that no longer match the new CRM structure.

Migration also requires decisions about relationships. Contacts need to remain connected to the right companies, deals, activities and other records. Record ownership, notes, attachments and historic information may also need to be retained.

Cleaning the data before migration is usually more effective than importing everything and attempting to repair it afterwards. Test migrations are equally important because they allow relationships, field mappings and formatting to be checked before the final move.

A carefully configured CRM cannot compensate for unreliable source data.

Depending on the project, you're paying for discovery to understand how the business operates, CRM architecture to determine how those processes should be represented, and then the actual configuration of modules, fields, layouts, pipelines, permissions and reporting.

There may also be data migration, including cleaning and restructuring existing information before it can be imported properly. Automation and integrations need to be designed, built and tested. Users need training, and somebody needs to manage the transition from the old way of working to the new system.

At a basic level, an MCP connection involves an AI application acting as a client and an MCP server exposing information or capabilities that the AI can use. The server effectively tells the AI what it has access to and how those capabilities can be used.

Imagine, for example, that an organisation connects its CRM to an AI assistant through MCP. Rather than exporting sales data into a spreadsheet and uploading it to ChatGPT or another AI tool, someone could simply ask which opportunities have not been contacted during the past fortnight. The AI could retrieve the appropriate records from the CRM and produce an answer based on live information.

The more significant change comes when the AI is allowed to perform actions as well as retrieve information. Having identified those neglected opportunities, the user might ask the AI to create follow-up tasks for each account owner. Provided the relevant tools and permissions have been made available, the AI could carry out the request in the CRM rather than merely explaining how the user should do it.

This distinction between retrieving information and performing actions is central to understanding why MCP is attracting so much attention. Connecting AI to business systems is useful because it gives the model better context, but connecting it to the functions within those systems opens up the possibility of AI becoming an active participant in business processes.

Most business use of generative AI still revolves around producing something for a person. An employee asks for an email, summary, report, calculation or piece of analysis, receives an answer and then decides what to do with it.

That model is already useful, but it leaves the employee responsible for moving between the AI and the applications where the work actually happens. If an AI assistant identifies that ten sales opportunities require attention, somebody still has to open the CRM, find those records and create the necessary tasks.

MCP is part of a broader move towards AI agents, where the objective is not simply to generate an answer but to allow AI systems to use tools in order to complete a task. Once an AI can securely access the systems a business already uses, the range of useful tasks becomes considerably wider.

Consider a fairly ordinary request such as asking an AI assistant for an update on a particular customer. A useful answer might require information from several places. The CRM contains the customer's sales history and current opportunities, the finance system contains invoices and payment information, the support platform contains outstanding issues and the project management system shows the progress of ongoing work.

Today, an account manager might open each of those applications and piece together the information manually. With appropriate MCP connections, an AI agent could potentially retrieve the relevant information from each system and produce a single account summary.

The employee could then ask it to create a task for an overdue sales follow-up, prepare an email regarding an outstanding invoice or summarise an unresolved support issue. Rather than AI being another application that needs to be checked, it starts to become a way of interacting with the applications the business already has.

Workspace Studio originally focused more on helping a user with a task, such as drafting an email. Google is now introducing more cross-user collaboration actions, alongside controls for identity, access, auditing, human approval and data protection.

For newly created flows, Google says the automation will run with the user’s identity but receive only the privileges needed for the flow. It can also receive a unique, auditable identity, so an administrator can distinguish the flow from its owner when reviewing activity.

That is a useful improvement, but it does not repair untidy access permissions. Google’s administration guidance says a newly created flow can, by default, read, modify and share the same Workspace data its creator can access. If that person can see too much, the automation may still inherit a wider data footprint than the process needs.

Administrators are also getting an Agent access management view. It can show new Studio flows, pause their access to Google data or restrict particular access scopes. Audit events can include the flow identifier and owner context, while additional settings can disable certain steps, Gemini data access or webhook integrations.

Google began rolling out the administration settings to Rapid and Scheduled Release domains on 17 August. Rapid Release end-user features started on 20 August, while broader Scheduled Release end-user features are due to begin on 1 September. Identity attribution is still labelled beta; its Scheduled Release rollout is due to start on 24 August.

Availability will therefore vary by tenant and release track. More importantly, the first wave of least-privileged identity, identity attribution, richer audit context and Agent access management applies to newly created flows. Google says support for existing flows will come later.

That creates a practical review point. An organisation with older flows should not assume the new dashboard and identity model cover them simply because the administration controls appear in the console.

1. Start with one bounded process. Choose a repetitive task with clear rules, a visible outcome and an easy way to reverse mistakes. Creating a standard project folder and notifying the delivery team is a better pilot than allowing an agent to decide what happens across an entire customer journey.
2. Map data and permissions first. Record what the flow needs to read, what it can change, who owns it and what it must never access. Review the creator’s underlying Drive, Gmail and group permissions before relying on the phrase “least privilege”.
3. Keep approval around consequential actions. Require a person before external sharing, payments, personal-data handling, access changes or contractual communication. Automation should remove friction, not accountability.
4. Separate new and existing flows. Build an inventory with owner, purpose, data access, release date and review date. Confirm which flows appear in Agent access management and which still operate under the older model.
5. Review flows like user accounts. Recheck them when an owner changes role, a process changes or the data becomes more sensitive. Pause or retire flows that no longer have a clear business owner.

Google’s controls are a useful step towards that balance. They provide better visibility and a more credible way to limit action, but the rollout is not complete, older flows are not yet fully covered and advanced data protection remains edition-specific. Doing nothing for a week or two is reasonable if your tenant, ownership model or permissions are not ready.

For most SMEs, the right move is a small, measurable pilot with clear boundaries. Automate one high-friction process, watch what the flow can access and keep a person responsible for the result.

Calling something a bubble can make it sound as though the underlying thing is fake. That is not really what a financial bubble means.

Strictly speaking, economists generally use the term for a situation where the price of an asset moves beyond what its underlying fundamentals can reasonably justify. Bubbles can become self-reinforcing: rising prices attract investment, that investment creates further growth and confidence, and the apparent success encourages even more money to enter. Eventually the fundamentals have to catch up with the expectations. If they don't, the process can reverse. 

With AI, we are using the word slightly more broadly. The concern is not simply that a handful of AI shares are expensive. It is that valuations, infrastructure spending and business plans across an entire industry increasingly depend on very optimistic assumptions about how much AI customers will eventually consume and how much they will be prepared to pay for it.

That distinction matters because a technology can be genuinely transformative and still have a financial bubble built around it.

AI could follow a similar pattern.

Microsoft said in July that its calendar-year 2026 capital expenditure expectation was around $175 billion after an accounting-related lease change. It spent $41 billion in its latest quarter alone, with roughly two-thirds going towards relatively short-lived assets such as CPUs and GPUs. Amazon has said it expects to invest about $200 billion across the business in 2026, while its latest results said the large increase in property and equipment purchases primarily reflected AI investment. Meta expects capital expenditure of between $130 billion and $145 billion this year. 

And to be fair, there is real demand behind it. AWS revenue grew 37% year-on-year in Amazon's latest quarter, Microsoft said Azure revenue grew 43%, and Microsoft 365 Copilot has passed 30 million paid seats. This is one reason we don't buy the argument that AI is simply a fad waiting to disappear. 

There is also an unusual dynamic inside the AI economy. The companies building the infrastructure are not always simply selling computing power to independent customers. They are also investors and strategic partners in some of the AI companies consuming huge quantities of that infrastructure. Microsoft's financial results, for example, now separately discuss the effects of its OpenAI investment, while Amazon's latest quarter included a very large accounting gain from its investments in Anthropic. 

The argument in Ed Zitron's recent piece about an "AI demand bubble" takes this much further, arguing that the industry is dangerously dependent on a relatively small number of heavily funded AI labs buying enormous amounts of computing capacity. We wouldn't treat the analyst estimates used to make that case as established fact, particularly because the cloud companies do not disclose enough detail to verify them. But the broader question it raises is a sensible one: where does the money eventually come from once you follow the chain all the way back to the end customer?

A recent NBER study surveyed nearly 6,000 senior executives across the UK, US, Germany and Australia. It found that 69% of firms were already using AI in some form. But 89% of executives said AI had made no measurable difference to labour productivity at their business over the previous three years. Among the minority reporting an impact, the researchers estimated the average productivity increase across all firms at just 0.29%. Executives expect substantially larger benefits in the years ahead, which may turn out to be correct, but that gap between what AI has delivered so far and what businesses expect it to deliver next is exactly where the financial risk sits. 

We don't think there will necessarily be a morning where everybody collectively decides AI was a mistake.

A more believable version is much less dramatic. Growth remains strong, but not quite as strong as investors expected. Businesses become more selective about the AI tools they pay for. A few heavily funded AI companies struggle to justify another enormous funding round. Some data-centre projects are delayed. Investors start demanding profits rather than promises of future scale.

Once expectations change, the same feedback loop that helped inflate the market can begin to work in reverse.

Private AI businesses that could previously raise money based on what they might become in five years suddenly have to explain how they make money today. Dozens of companies selling broadly similar AI products consolidate or disappear. Features that once commanded a £20 or £30 monthly add-on get bundled into existing software. Model providers compete harder on price, pushing the underlying technology towards becoming a commodity.

So a burst may look less like AI suddenly disappearing and more like a fairly brutal repricing of who actually captures value from it.

There would still be GPUs running, data centres operating and businesses using AI. There would simply be fewer companies able to justify enormous valuations on the assumption that they will eventually own a large part of the market.

The lesson of the dot-com bubble isn't "new technology gets overhyped and fails". It is almost the opposite.

The internet really did transform commerce, communication, entertainment and almost everything else. But being correct about the importance of the internet did not automatically make investors correct about which businesses would win, how quickly the opportunity would develop or what those businesses were worth in 1999.

That is the comparison we think makes sense for AI. It is completely possible that today's AI boom is simultaneously producing one of the most important technologies of our generation and a spectacular amount of bad investment.

In fact, those two things often go together. A genuinely important technological shift makes an especially convincing investment story because there is something real underneath the hype. Nobody has to invent the potential of AI. You only have to exaggerate how quickly that potential turns into revenue, or assume that your particular company will be one of the businesses collecting it.

You can read more about what we're doing and the thinking behind it on our Sustainability page as well as in our Sustainability Policy.

That is no longer just a future concept. Google and OpenAI now offer enterprise systems specifically designed around agents that connect to company tools, follow permissions and operate across multi-step workflows. Gartner forecasts that up to 40% of enterprise applications will contain task-specific agents by the end of 2026, compared with less than 5% when it made the forecast in 2025. 

But there is an important reality check. Stanford’s 2026 AI Index found that actual agent deployment was still in the single digits across nearly all business functions during 2025. 

The biggest AI change may be the one you notice least.

That makes sense for a business.

Opening another AI website, copying information into it and then copying the result back into your CRM is not much of an automation. The bigger opportunity is AI working directly inside your email, CRM, finance system, help desk or document workflow.

For an SME, that could look like an incoming enquiry being classified automatically, a CRM record being updated, a draft response being prepared and the right colleague being asked for approval.

The AI itself becomes less interesting. The workflow becomes more important.

Stanford’s review of productivity research found some of the largest gains in structured, measurable tasks, including customer support, software development and marketing output. OpenAI’s own enterprise research similarly reports substantial numbers of users seeing faster marketing execution and IT issue resolution. 

Current enterprise AI platforms are moving in exactly this direction. Google, for example, now supports multiple first-party and third-party models inside one agent platform, alongside orchestration, identity, security and evaluation tools. 

That is useful because the “best” model will keep changing. Stanford reports that leading models are increasingly close on headline performance, shifting more of the practical decision towards reliability, cost and performance for a particular domain. 

The UK government’s voluntary AI cyber security code calls for defined business requirements, security risk assessment, staff training, audit trails, controlled permissions, testing and human responsibility. EU requirements also impose human-oversight duties in specified high-risk uses. 

Wise is right about the overall direction: AI is moving deeper into everyday business processes, agents are becoming more capable, and people will increasingly supervise AI rather than simply ask it questions. 

Businesses are using more apps than ever - and that complexity is expensive. Okta’s 2025 Businesses at Work report states that the global average number of apps per customer has topped 100 for the first time, driven by 9% year-on-year growth.

More tools usually means more silos. Salesforce reports 81% of IT leaders say data silos are hindering digital transformation.

As organisations push more automation and AI into operations, data quality becomes non-negotiable. Gartner states that poor data quality costs organisations at least $12.9 million a year on average.