Oracle and OpenAI aim to bring business workflows into ChatGPT

Oracle brings business workflows towards ChatGPT

Getting an answer from a business system is useful. Getting approved work done across several systems, without carrying everything between them yourself, is the bigger prize Oracle and OpenAI are pursuing.

Our main story today is Oracle's expanded partnership with OpenAI: how much of the work between a request and a completed business task could happen inside ChatGPT?

Announced on 27 October, the partnership covers Oracle applications and data in ChatGPT, alongside enterprise application development using Codex. Oracle AI Workspace is being developed to connect business applications through that conversational interface, retaining an organisation's permissions and approvals. OpenAI describes it as the intended experience. The appeal is easy to understand: you ask for an outcome, and the software can help carry the work across the applications involved.

Consider the difference between asking for information and asking for a change. Reading a business record might require one level of access. Updating it might require another. Approving the update could belong to someone else entirely. Those distinctions are part of the workflow, even when the person making the request sees one chat box. A useful conversational interface has to carry that organisational context along with the words you type.

That's why the permission handling is so central to this announcement. If a request reaches the right system with the right authority, it could remove some of the manual work of finding records, passing information between applications and waiting for the next person to pick it up. If the connection stops at retrieving information, the employee still has the remaining steps to do. The interesting measure is how far a task gets through its existing process.

Oracle is also planning App Composer, powered by Codex, for enterprise application development. That addresses a related problem: someone has to build the software that connects an organisation's particular work to its existing systems. Putting a coding tool alongside the proposed workspace brings application creation into the partnership as well. The two efforts could reinforce each other, with developers building the connections and employees using them through a familiar conversational interface.

There is a concrete purchasing change already. US customers can buy the OpenAI API, Codex and ChatGPT Work through Oracle Marketplace using eligible Oracle Universal Credits. For organisations with those credits, this adds a procurement route through an existing commercial relationship. The immediate question for a buyer is which purchases fit that arrangement and their available credits. Procurement staff can assess those products through the Marketplace arrangement alongside their organisation's existing Oracle commitments.

For Australian organisations, general launch dates, pricing and local availability for Workspace and App Composer remain unspecified. That puts the proposed workflows in the planning conversation, while the current Marketplace purchasing change applies to US customers. An Australian rollout schedule can't yet be built around this announcement.

My read is that the strongest opportunity sits in the handoffs between systems. A person can spend considerable effort getting an otherwise straightforward task from a request to an authorised change. Reducing those handoffs could be valuable even when the underlying business applications stay exactly where they are. It also gives organisations a concrete way to judge the proposed experience: how much work reaches completion, and how much still comes back to the employee to move along? The value will depend on those connections carrying the task all the way through.

IBM gives agents scoped identities

That leaves Oracle's bigger workflow plan ahead of us. IBM has a more immediate release for managing the agents doing that work.

On 26 October, IBM made Agent Identity generally available. It combines agent registration, delegated authority, access enforcement and audit records. In practical terms, an organisation gets a way to identify an agent, connect it to whoever authorised its work and control what it can access.

IBM describes short-lived, task-scoped OAuth tokens as a central part of the design. A token is a credential software presents when it asks another service to let it do something. Task-scoped means the permission is limited to the job involved; short-lived means it expires. The connection to the person or system that granted the authority stays attached to the agent's actions.

That has a useful consequence when an agent operates across several steps. The original instruction and the later access request can remain linked, giving an administrator a clearer answer to who authorised the work. Audit records then help reconstruct what happened. Registration, permission and history serve different purposes, and the product brings them together.

The architecture combines IBM Verify with HashiCorp Vault for credentials and integrates agents managed through watsonx Orchestrate. For organisations already working with those products, that makes the proposed fit more concrete: identity, credential handling and agent management have named places in the setup. An organisation using other systems still has the practical question of how this sits alongside its existing access controls.

I think limited authority is the most useful part of this release. An agent can make a poor decision within a legitimate task. Restricting which resources it can reach, and how long its permission lasts, could reduce the extent of the resulting mistake. That gives an organisation a control it can adjust independently of the model's ability to reason through the work.

It also makes the ownership question less vague. If an agent changes something, there is a person or system behind the delegation, and a record of the access involved. General availability lets organisations assess that design against their own operational requirements now. Deployment costs weren't set out in the announcement, so fitting it into an existing identity setup remains both an engineering and a purchasing decision.

SAP puts Joule into more workflows

There's a useful view from an early customer of how these business agents behave once people start using them.

At TechEd on 27 October, SAP announced expanded Joule Work and Joule Studio capabilities for multistep business workflows and connections to third-party agents. Joule Studio early adopters can now design and run n8n workflows, with wider availability to follow. n8n provides a way to connect steps in an automated workflow, so this gives those customers another route for assembling work across tools.

SAP also announced interoperability through A2A and MCP, alongside additional governance controls. Broadly, A2A concerns communication between agents, while MCP gives models a common way to connect with tools and context. These connections are useful when the work reaches beyond a single application. They give the different pieces a way to exchange requests and information.

Bosch's experience adds some practical texture. In conference reporting from diginomica, the company described reliable answers, response times, access management and costs as issues still to resolve before wider deployment. That's a particularly useful set of concerns because each one affects a different part of an employee's day.

A response can arrive quickly and still need correction. An accurate answer can arrive too slowly to fit the task. Access management determines whether the person can reach the information or perform the action in the first place. Cost then affects how widely the organisation can afford to use the system. Improving one of those doesn't automatically settle the others.

For a multistep workflow, those considerations also interact. Waiting occurs between steps as well as at the initial question. A permission problem halfway through can leave work unfinished. Extra review can add to the effort involved in getting an answer into usable shape. Those are concrete reasons to examine the whole task when assessing an agent.

The Bosch account gives me a better yardstick for this release than the number of available connections. I'd look at whether a representative piece of work gets easier to complete, at an acceptable response time and cost. The expanded tools give early adopters more to test against that yardstick. Access still varies by capability, including the restricted n8n rollout, so organisations can match their evaluation to the specific features available to them.

Google opens cloud access to robotics reasoning

Let's leave the office software for a moment, because connecting an AI model to a robot adds a very physical handoff.

On 27 October, Google brought its existing Gemini Robotics Embodied Reasoning 2 model into public preview through its enterprise cloud platform. Robotics developers can access it using Google Cloud authentication and infrastructure. The change is a new integration route for the model, which handles high-level visual reasoning, task planning and tool calls.

The word reasoning is important here. This layer works on understanding a scene and deciding what to do next. Developers still connect robot-control interfaces or lower-level action models, the pieces that turn a plan into commands for a particular machine. A model can help choose a step while a separate system handles the mechanics of carrying it out.

That division is useful because the same high-level intention can require different actions from different robots. The available controls, the machine's movement and the environment around it all shape the implementation. The developer-supplied interface is where a proposed task meets the capabilities of the hardware. It's a substantial part of building the working system.

Cloud access could make one portion of that job more straightforward. Developers using Google's infrastructure have an authentication and service environment through which to integrate the reasoning model. That could reduce work around access and service plumbing, leaving more attention for the robot-specific connection. It also makes the model available for evaluation through an enterprise platform that organisations may already use.

The material limits are preview maturity and the physical environment. Google's documentation says the model can produce incorrect information, and operators remain responsible for maintaining a safe setting. For a robotics developer, that translates into engineering the control system and operating conditions around the actual machine. A high-level plan is one input into that system.

I see this as a useful opening for developers who have robot interfaces to connect and want to explore a reasoning layer above them. The practical gain is easier access to that layer. Progress can then be judged at the point where the plan becomes action: whether the connected robot can carry out the task appropriately in its intended environment. That's where the remaining integration work becomes visible.

Meta tests AMD Helios racks

At the other end of the hardware scale, Meta is testing a new rack-scale system from AMD.

AMD announced on 27 October that initial Helios systems are installed and being tested at Meta. Alongside that technical milestone, AMD committed one billion US dollars to Meta's equity offering. A chip supplier is expanding its relationship with a major customer through both equipment and investment.

The current stage for Helios is testing ahead of broader deployment. AMD's Instinct graphics processors already serve production training and recommendation workloads at Meta, according to the announcement. That gives the relationship an existing production base, with the new rack-scale systems now going through their own evaluation.

A rack-scale system is assessed as more than an individual processor. For an operator, the useful question is how the assembled hardware fits the workloads and the infrastructure around it. Testing at Meta brings Helios into that operating context. It gives the prospective customer a way to examine the system where broader deployment is being considered.

The announcement provides no independent Helios performance results, size for the test installation or firm date for the broader rollout. Those details would help other infrastructure buyers judge how far the system has progressed and how relevant the experience is to their own plans. For now, the concrete milestone is the installed equipment undergoing tests.

The equity investment adds a separate commercial dimension. AMD becomes financially involved in the company buying its technology, alongside the supply relationship. That makes the commercial package more intertwined: a hardware decision and a financing relationship can sit beside each other even though they answer different needs.

For organisations planning large AI infrastructure, I think the interesting possibility is a broader choice of systems that can handle production work at scale. Meta's existing Instinct use and its new Helios testing are useful stages in that story. A successful evaluation could strengthen the case for the new hardware, while the investment shows how much of this competition now extends into the financial relationship between supplier and customer.

EU data rules enter negotiations

Europe's privacy negotiations also have a practical consequence for anyone planning how to use personal data in AI.

On 21 October, the Council of the European Union agreed its negotiating position on a digital simplification proposal covering data protection, cookies and incident reporting. The announcement was updated with the mandate text on 22 October.

The Council's position keeps the current definition of personal data and proposes safeguards around exceptions for processing sensitive data in AI development and operation. Keeping that definition preserves an important starting point for deciding which information falls within the rules. The proposed exceptions and their safeguards concern what can happen with sensitive information in particular circumstances.

This is the governments' negotiating mandate. Talks depend on the European Parliament adopting its position, and the final text and starting arrangements remain to be settled. Organisations continue to work under their current GDPR obligations; the Council vote creates no new permission to use personal data for AI.

For businesses operating in Europe, the useful issue to follow is how the eventual text handles those specific exceptions alongside simpler compliance processes. My view is that practical simplification will be judged by whether organisations can understand and apply the rules with less effort while the limits on data use remain enforceable. There's a negotiating direction to examine now, with operational changes dependent on the legislation that emerges.

GitLab fixes a critical server flaw

For anyone running their own GitLab server, the action is much more direct: there's a critical patch to apply.

GitLab's 21 October security release addresses a regular-expression compiler flaw that could allow an unauthenticated attacker to execute code on an affected server. Unauthenticated means the attacker wouldn't need to log in first. GitLab gives the vulnerability a severity score of ten out of ten.

The identifier is CVE-2026-110264. Fixed releases include 19.5.1, 19.4.3 and 19.3.6, with backports available for older branches. Operators need the applicable fixed release for their installation, so the relevant patch depends on the version they're running.

GitLab.com was already patched when the advisory appeared. People using that hosted service don't need to update it themselves. The work sits with operators of affected self-managed installations.

I'd put this high on the maintenance list because code execution on a service inside the software-development environment deserves prompt attention, particularly when login isn't required. The useful next step is concrete: get the affected installation onto its appropriate fixed release. That closes the disclosed flaw at the service where it exists.

What Changes for You

If your work starts with a pile of scanned documents, there's a new component you can evaluate on your own infrastructure.

Baidu released downloadable Unlimited OCR 2 weights and a public demo on 27 October. OCR turns images of pages into text. This model accepts an ordered sequence of pages in one request, allowing it to use context across page boundaries. That's useful for content whose meaning or structure continues from one page to the next.

Baidu says its sparse-reference attention approach limits how much memory grows at each processing step as documents get longer. The serving instructions expose a practical trade-off: smaller page windows reduce peak memory use, but can damage the merging of content across page boundaries. So the choice of how many pages to process together affects both the computing load and how well the pieces join up.

Working AI builders can download the weights and assess the component with their own documents. Self-hosting gives them control over where processing runs, which could be useful when document handling needs to stay within a chosen deployment. It also puts the hardware, software setup and output checking in their hands.

The published setup was tested on an NVIDIA A800 with eighty gigabytes of memory and uses specialised software. That's the test configuration; the release doesn't establish it as a minimum requirement. It does give a builder a concrete reference point when considering available hardware and the effort involved.

For me, the attractive part is control over document ingestion and data location. The engineering question is whether the text stays usable across the page boundaries that matter in your material, within the memory your deployment can provide. Smaller windows may help it fit, while preserving those joins determines how much work the extracted text saves.