OpenAI is selling its first hardware — without any help from Jony Ive. It describes the Codex Micro as a “command center for agentic work” but it’s really a 13-switch wireless keyboard customized to help developers keep tabs on what their Codex agents are doing. It costs $230.

The keyboard has 13 mechanical switches (one keycap covers two of them by default), a rotary encoder, joystick, and RGB backlighting around the whole keypad and individual keys. It comes with 32 customizable icon keycaps.

OpenAI claims that the Codex Micro is a serious business tool: The command keys enable Codex users accept changes, reject outputs, push-to-talk, start new chats, and trigger custom actions. The rotary encoder can be used to dial up the “brainpower” allocated to tasks — or in more conventional terms, how many tokens to allocate to reasoning on a task. And the RGB lighting can provide feedback on how various tasks are progressing. And the RGB lighting under the “agent” keys can provide feedback on how various tasks are progressing.

The Codex Micro’s manufacturer, Work Louder, already has a similar device on the market, the Creator Micro, which offers similar functionality, but without the colorful keys. It costs $56 less than the Codex Micro, however.

The Codex Micro will fit in snugly with OpenAI’s other merchandise, where using Codex is as much about a fashion statement as a technological choice.

Linus Torvalds has a complicated relationship with AI, seeing both its good and bad points. But his latest remarks on the usefulness of AI may have raised a few eyebrows in open-source circles.

Just a few weeks after the Linux founder complained that a “continued flood” of AI-generated vulnerability reports had made the Linux kernel security mailing list “almost entirely unmanageable”, he has come to see the advantages of the technology.

“Linux is not one of those anti-AI projects,” Torvalds wrote in an email response to Linux Kernel senior engineer Roman Gushchin, archived at Kernel.org.

“It can also be a somewhat painful tool, both for maintainer workloads and just from a ‘it keeps finding embarrassing bugs’ standpoint,” he said of the use of AI in security scanning. “The solution is to make sure those LLM tools help maintainers instead of just causing them pain.”

Developers should be free to choose whether they use AI, he said. “We’re not forcing anybody to use it, but I will very loudly ignore people who try to argue against other people from using it.”

Torvalds’ measured support for AI does not come completely out of the blue: Around the same time that he was complaining about AI distorting security maintenance, he also spoke about its usefulness, claiming that it could improve programmer productivity by a factor of 10.

Thinking Machines Lab, the San Francisco startup founded by former OpenAI CTO Mira Murati, has released Inkling, its first general-purpose AI model. The launch adds another US-developed entrant to an open-weight market where Chinese developers produce several leading coding and reasoning models.

Inkling uses a mixture-of-experts architecture with 975 billion total parameters, of which 41 billion are active during processing. It supports a context window of up to 1 million tokens and was pretrained on 45 trillion tokens spanning text, images, audio, and video. Thinking Machines said it also trained the model for coding, tool use, and multimodal tasks.

The release follows the October 2025 launch of Tinker, Thinking Machines’ first product and an API-based platform for customizing AI models. Developers can fine-tune Inkling through the platform.

In a June 2026 assessment, AI model routing platform OpenRouter highlighted DeepSeek V4 Flash, GLM 5.2, MiniMax M3, and Nvidia Nemotron 3 Ultra as four notable open-weight models. Nemotron was the only US-developed model in the group.

Performance and developer access

Thinking Machines Lab’s benchmark table shows mixed results. Inkling scored 77.6% on SWE-Bench Verified, behind DeepSeek V4 Pro and GLM 5.2 but ahead of Nvidia Nemotron 3 Ultra. It also recorded 74.1% on MCP Atlas, 77.1% on BrowseComp with context management, and 79.8% on IFBench.

Thinking Machines said Inkling’s result used a bash-only harness, while the comparison figures were reported by the competing models’ developers.

The model includes a reasoning-effort setting that developers can adjust from 0.2 to 0.99. Thinking Machines said the setting allows users to balance performance against the number of generated tokens. In the company’s testing, Inkling matched Nemotron 3 Ultra’s Terminal Bench 2.1 score while generating about one-third as many tokens.

Developers can fine-tune Inkling through Tinker using context lengths of 64,000 or 256,000 tokens and test it through the Inkling Playground. The model is available through APIs from Together AI, Fireworks, Modal, Databricks, and Baseten. It is also supported by inference software, including SGLang, vLLM, TokenSpeed, llama.cpp, and Hugging Face Transformers.

Inkling’s full weights are available on Hugging Face as the original checkpoint and as a quantized NVFP4 checkpoint. Thinking Machines also previewed Inkling-Small, which has 276 billion total parameters and 12 billion active parameters. The company said it would release the smaller model’s full weights after completing testing.

Enterprise impact

Inkling’s differentiation lies in its open weights, multimodal capabilities, controllable reasoning, and integration with Tinker, rather than benchmark leadership, according to Biswajeet Mahapatra, principal analyst at Forrester.

“Enterprises are most likely to benefit in workloads where domain adaptation matters more than generic model performance, including knowledge-intensive copilots, multimodal customer service, document understanding, operational workflow automation, and agentic tasks that require organization-specific data, policies, and processes,” Mahapatra said.  

Inkling’s US origin could also influence adoption among Western enterprises, according to Pareekh Jain, CEO of Pareekh Consulting. He said many Western organizations face regulatory or procurement barriers when considering Chinese-developed AI models.

“Inkling gives those organizations a US-developed open-weight option that they can deploy on their own infrastructure,” Jain said.

However, the benefits will need to be weighed against the cost of deploying the full model.

Running Inkling on private infrastructure requires a GPU cluster with at least 2 TB of aggregated VRAM for the BF16 checkpoint, according to the model card. Thinking Machines lists configurations of eight Nvidia B300 GPUs or 16 H200 GPUs. A quantized NVFP4 checkpoint lowers the requirement to at least 600 GB and can run on four B300 GPUs or eight H200 GPUs.

“Because Inkling is a massive model with 975 billion total parameters, running the full model still requires significant GPU infrastructure, making closed-model APIs more economical for many organizations,” Jain said.

Jain said Inkling-Small may be a more feasible option for many enterprises because it could reduce infrastructure costs and latency while retaining useful performance across key workloads.

Safety and governance

Thinking Machines said it trained Inkling for calibration, instruction following, and resistance to censorship. The company said the model showed “strong patterns of censorship non-compliance” when evaluated by Cognition on its Propaganda and Censorship Eval.

Inkling scored 98.6% on StrongREJECT, which Thinking Machines described as a test of whether models refuse unambiguous harmful requests.

The model’s safety behavior should be retested after an enterprise customizes it, according to Jain. “Model fine-tuning can weaken safety filters, so companies should retest safety after customizing the model rather than assuming it stays safe,” Jain said.

He added that self-hosted and modified versions could diverge from Thinking Machines’ official model over time without receiving automatic updates.

“CIOs need to ensure every AI agent action is logged, auditable, and governed by human approval for high-risk tasks,” Jain said.

OpenAI’s recent update to its Codex CLI has introduced a new protocol that appears to shift more orchestration decisions from user-defined configuration to the runtime, prompting developers to request greater visibility into the instructions exchanged between AI agents.

In a detailed GitHub merged request, users stated that the Multi-Agent V2 protocol-infused architecture of the CLI no longer exposes the instructions passed between parent and sub-agents, making it difficult to inspect how work is delegated across the system.

“Multi-agent v2 currently routes agent instructions through normal tool arguments and inter-agent context. That means the parent model can emit plaintext task text, Codex can persist it in history/rollouts, and the recipient can receive it as ordinary assistant-message JSON,” the request read.

“This changes the v2 path so agent instructions stay encrypted between model calls: Responses encrypts the message argument returned by the model, Codex forwards only that ciphertext, and Responses decrypts it internally for the recipient model,” it added.

Other users, commenting on the thread, also said that the lack of visibility into agent instructions can be attributed to the recently introduced Multi-Agent V2 protocol, with one user stating that reverting to the previous version of the CLI restored visibility, but only as a temporary workaround.

Separately, Ignat Remizov, CTO at payment service Zolvat, filed a GitHub feature request to offer what can be described as a permanent fix after stating that OpenAI may have introduced the change in efforts to harden security.

“A possible shape is to keep the encrypted message field for model delivery, but add a separate non-encrypted audit field for the readable task text. The audit field should be persisted in rollout/history/trace metadata so users and maintainers can inspect what was delegated without needing to decrypt model-delivery ciphertext,” Zolvat wrote.

Enterprise governance concerns are likely to emerge

While an OpenAI contributor said the protocol remains under development and declined further changes to the request, analysts warned that the issue would create debugging, governance, and operational challenges for development teams and their enterprises if the issue persists or becomes a long-term characteristic of multi-agent systems.

“Hidden agent instructions reduce observability in multi-agent systems. Developers can no longer see whether failures stemmed from incorrect task delegation, poor orchestration, or model reasoning, making debugging, prompt optimization, and root-cause analysis significantly harder. Agent instruction traces are becoming as essential as application logs in modern software,” said Pareekh Jain, principal analyst at Pareekh Consulting.

For CIOs, Jain pointed out, opaque agent interactions create governance challenges.

“Without visibility into how agents delegated and executed tasks, it becomes harder to audit decisions, investigate incidents, demonstrate compliance, and build trust in AI systems. Enterprises will increasingly expect secure but auditable agent communication rather than completely hidden orchestration,” Jain said.

“Any big enterprise, especially in regulated industries such as banks and hospitals, needs to be able to prove what their AI systems did and why, especially if something goes wrong. If a sub-agent does something bad, like touching private data, the company needs to show here’s exactly what it was told to do. If that record doesn’t exist, it is a serious problem for trust and legal accountability, not just an annoyance,” Jain added.

Further, the analyst pointed out that issues around the visibility of agent operations could even slow production deployments of mission-critical AI.

“Enterprises, just like we are seeing with developers on GitHub, are likely to demand stronger observability, audit trails, and governance before trusting autonomous multi-agent systems. It is nearly as important as model performance,” Jain added.

An email sent to OpenAI enquiring about planned changes to the protocol went unanswered.

These days, application developers can take their pick from a vast menu of architectural solutions. We can choose from the well-understood to the experimental, and from blended solutions in between. Several powerful middle-ground technologies that emerged during the cloud revolution have really come of age. Here we’ll take a look at putting together three of the most impressive: GitHub, Vercel, and Firestore.

Each of these is an important tool in its own right that can be used to attack specific problems. In combination, they not only meet the needs of several important application scenarios, but they have a superpower—the ability to dramatically shorten the distance between development and deployment.

There is nothing quite as gratifying as putting your hands on just the right mix of tools for a given need.

A ‘no-ops’ stack built for speed

If your primary goal is sheer development velocity, you would be hard-pressed to top this architecture. This “no-ops” stack collapses the distance between your local IDE and a globally distributed production environment. You are essentially trading the overhead of managing VMs and load balancers for the sheer speed of committing code and watching it deploy automatically.

While each component is highly flexible, adopting them requires a specific, event-driven mindset. There are a few finicky bits to manage, mostly around routing environment variables securely and designing around stateless back-end functions. But the constraints are obvious and well-documented.

Before we look more closely, let’s quickly identify the kinds of apps that are a perfect fit here, along with those that are workable and those that really merit a different approach.

• The sweet spot (deploy and go): AI-mediated applications, asynchronous game back ends, and real-time collaborative B2B dashboards. This architecture perfectly absorbs the unpredictable latency of LLM APIs and instantly syncs state across multiple clients without requiring you to build custom WebSocket infrastructure.
• The middle ground (workable, with trade-offs): Headless e-commerce, moderate IoT telemetry, and apps requiring scheduled batch processing. You will encounter friction if your catalog relies on deeply relational SQL constraints, or if your background reporting jobs take longer than a few minutes and hit serverless execution limits.
• The danger zone (look elsewhere): High-frequency trading, fast-paced action multiplayer games, heavy data ETL pipelines, and core financial ledgers. Serverless architectures cannot natively hold open the persistent WebSockets required for twitch-reflex data, and heavy compute tasks will abruptly time out.

We should mention that these categories are not mutually exclusive. Many enterprise applications, such as a full-scale e-commerce platform, straddle these lines. You might use Vercel and Firestore to build a lightning-fast, reactive storefront that handles ephemeral user state like shopping carts, while simultaneously “stitching in” a managed SQL database like Supabase or PlanetScale. This hybrid approach allows you to maintain the relational integrity required for back-office inventory and financial ledgers and pair it with the front-end velocity this stack provides.

GitHub: the bedrock

I don’t need to introduce you to GitHub. It is a central element of the development landscape. I still remember CVS and SVN with a certain nostalgia, but the enhancements of Git speak for themselves. When combined with the orchestration powers of GitHub, it is no wonder that virtually the whole industry has adopted this type of platform.

Git plus GitHub gives you an enormous amount of power already, in terms of how you can organize and automate your projects. But there is a next-level experience in combining GitHub and Vercel. For JavaScript-based projects, you can take simple GitHub pushes and turn them into instantly deployed clients and serverless functions. It is one of the cleanest and least fiddly ways to move from raw code on your local machine to a globally deployed, full-stack architecture.

Vercel: the nexus

Vercel is more than just a deployment host. It is a control plane that ties this high-velocity, no-ops architecture together. Alongside GitHub and Firestore, Vercel’s deeper strength is its ability to act as an orchestration layer between your reactive front end and external stateful services.

Vercel has a great amount of facility in fine-tuning what branches go to what environment and helpful features like instant rollback. You can just log into Vercel’s dashboard for your project and see the history of deployments and any errors and logs. It’s a simple menu choice to roll back to a historical version or compare one version against another.

When you “stitch in” third-party services (such as a managed SQL database like Supabase or a payment processor like Stripe), Vercel’s serverless functions become the lightweight interface, and Vercel’s the adapters handle the communication. You offload the integration logic (the service layer) to Vercel’s global Edge Network, keeping your UI and back end clean, responsive, and decoupled. 

In short, Vercel allows you to get the speed of the “no-ops” development life cycle without sacrificing the complex transactional integrity required for some applications like enterprise inventory systems.

Firestore: the datastore

Firestore is an extremely lightweight, NoSQL, cloud datastore. It has a great deal of add-on power, but its core value proposition is that it accepts virtually any data you stuff into it and it provides event-driven subscriptions to data changes.

These two capabilities together make Firestore about as straightforward a solution to a managed back end as you can imagine. You subscribe to collections or even fields and then you simply stick “unstructured” data (read: JSON with variable fields) in and the client waits for the changes it is interested in.

This is so streamlined that one can just point the browser (or native mobile app) directly at Firestore and listen for events. Which immediately raises the question of identity, for auth and for data visibility, but hold on—Firestore’s third superpower is that it has an authentication module that actually works. What I mean is, it is actually pretty simple and yet confidently secures your app.

Sometimes auth solutions seem either too simple (and yet opaque) or too mired in the nitty gritty. Firestore auth will let you do some basic configuration and start using a reasonable auth almost immediately. 

Not to belabor the point, but having a realistic and attainable auth solution elevates your stack to a production grade—one that can handle many real-world applications. Firestore auth plays nicely with other important APIs, like Stripe. Typically, auth is a major feature that feels like off-roading in a Honda Civic, but Firestore’s approach to auth, added to this particular stack, feels like a normal speed bump. It’s just another component you plug in, rather than a tentacled alien you weave into the your code.

The limits of the velocity stack

This architecture combines components that are optimized for flexibility. That same character also introduces distinct limitations. Understanding these is essential before committing production workloads.

The serverless life cycle

Serverless functions are spun up to handle requests. They close out soon afterward and lose any state. For that reason, they cannot natively hold open persistent WebSockets. If your system requires continuous, sub-millisecond, bidirectional streams—like a real-time multiplayer action game or a high-frequency trading dashboard—pure serverless will fight you all the way. You are forced to introduce a third-party managed WebSocket service to route messages back to your stateless endpoints via HTTP webhooks.

The execution time ceiling

Vercel (like all serverless platforms) enforces strict timeouts on operations. While enterprise tiers might grant you up to 15 minutes, standard functions often time out after 10 to 60 seconds. Long-running tasks like video transcoding, database scripts, or orchestrating multi-step AI agent workflows, which might take 20 minutes to resolve, will run up against these limits. Heavy-lifting tasks must be offloaded to a dedicated, long-running service like Google Cloud Run, or broken into smaller, asynchronous chunks via message queues.

The cold start reality

While the industry has made massive strides in minimizing initialization times—particularly with lightweight edge networks—traditional Node.js-based serverless functions still experience cold starts. If a function has not been invoked recently, or if traffic spikes require a new instance to spin up concurrently, the first request will take a noticeable latency hit as the container provisions and the code loads.

API instead of RAM

In a traditional server environment, you can store transient data in global RAM, allowing subsequent requests to access shared context instantly. In the serverless model, every request might hit a fresh container. Therefore, all shared context must be externalized. Although Firestore serves brilliantly as the state manager, relying on a database for high-frequency, sub-millisecond, ephemeral caching introduces network latency and per-operation costs. That said, using a shared RAM state on a server is non-trivial also, unless you are using a single app server and VM (because high-availability or fail-over requirements will lessen the RAM win on a traditional server).

Tuning for velocity and control

Every architectural decision is a trade-off. There are no cost-free choices. By adopting the GitHub, Vercel, and Firestore stack, you are explicitly maximizing feature velocity over fine-grained control.

You lose the ability to tweak the underlying operating system, hold open persistent sockets, or run hour-long back-end scripts. In exchange, you gain an architecture that scales from zero to global distribution instantly, requires virtually no devops maintenance, and perfectly absorbs the asynchronous, event-driven realities of modern application development.

For the right application—whether it is a fast-moving prototype or an enterprise AI copilot—this stack doesn’t just save time; it fundamentally changes how quickly a small team (or a single person) can impact the market. You stop worrying about build chains, load balancers, and server patches, and you focus on the central mission: shipping features.

The first time I heard someone say their AI now wrote 80% of their tests, I asked the obvious question. Eighty percent of what?

After 20 years building and leading test automation for consumer-scale platforms, my honest answer turned out to be eighty percent of the typing, not eighty percent of the engineering. The remaining twenty was where the work still lived. Budgeting for two percent of leftover effort was the mistake. When the real number was closer to thirty, that gap was the difference between a pipeline that shipped and one that quietly built up a queue of half-trusted features nobody could rely on.

This piece is about that gap. As an independent research project on LLM-augmented testing methodology, I built a six-stage agentic pipeline that takes a design in Figma and produces running tests in WebDriverIO, connected end to end over the Model Context Protocol. It works. It has been useful. And the parts that broke surprised me, because they were not the parts the hype cycle tells you to worry about.

How I wired a six-stage pipeline over one protocol

The pipeline runs six stages in sequence, each owned by a different agent, with every handoff crossing MCP.

Six-stage agentic test pipeline: design capture → requirements writer → ticket opener → code generator → test-case writer → automation generator. Each stage carries an MCP handoff and a provenance stamp.

The end-to-end trace links a pull request back to a Jira ticket, a requirements section and a Figma frame. Each artifact is stamped with the agent that produced it, the model it used and the inputs it was given.

MCP is the boring middle that makes any of this work. The cliché is that MCP is “USB-C for AI”: one open protocol, any tool. Like most analogies, it is about eighty percent right. The part that matters is the eighty: I do not have to write a custom adapter for every system the agent talks to. One MCP server per tool and every agent talks to all of them the same way.

Typed handoffs between agents are my own architecture, layered on top of MCP rather than provided by it. Each agent writes a typed artifact the next agent reads. Each handoff is logged with provenance. When something went wrong six stages in, I could replay the chain. Without that discipline, a multi-agent pipeline is a debugger’s worst day. You know the test plan is wrong. You cannot tell whether the mistake came from the Figma read, the requirements interpretation or the ticket scaffolding. With it, I could point at exactly which stage went sideways and which inputs it was looking at when it did. The pattern lives in a public MIT-licensed reference implementation for any reader who wants to run it.

The sixteen-minute number is the marketing number. I ran the full chain end to end in about sixteen minutes on a synthetic net-new screen, Figma in, automation suite out. That repeated across my runs; it is not a demo trick. But sixteen minutes is the part of the story most fun to tell and least useful to learn from. It is what gets quoted in the all-hands. The hours that come after, when a human reviews each handoff, are where the work actually lives.

What actually broke in production-style runs

The failures that stalled my pipeline were rarely the ones I expected.

I expected hallucinated APIs. I got them: the agent confidently called endpoint names that sounded right but did not exist. I expected sparse-spec-in, sparse-spec-out, where a Figma frame with no annotations produced a requirements doc with vague acceptance criteria, every time. I expected locator drift, the common UI-automation failure mode where a renamed component silently breaks an entire test suite. There is solid outside writing on non-determinism in tests covering this whole family of failure modes, and the agent inherited every one.

What I did not expect, and what kept the pipeline down longer than any of the above, was the plumbing.

The model backend timed out under load. It lost credentials silently and started returning empty strings, which the agent then read as confidence. A duplicate consumer on a shared long-poll API endpoint produced an HTTP 409 conflict that broke delivery without throwing anything visible. One unguarded exception inside one agent aborted a whole shared scheduler run and took the other agents in the registry down with it. The single worst incident cost me three hours to find. An environment variable had silently rotated overnight; every agent in the fleet was returning structurally valid but semantically empty requirements docs; the downstream stages were dutifully generating tests against nothing.

None of those are model bugs. They are infrastructure. The agent literature, which is what I went looking through when I started this work, mostly does not talk about them.

The fix was not better prompts. It was circuit-breaker-style review checkpoints between stages and what I now call the four-guard discipline: four small guards I consider non-negotiable on any unattended agentic pipeline. The bulkhead pattern from microservices is the most consequential. An unhandled exception inside one agent can no longer abort the shared run; the offending agent fails fast with a structured error and the others keep going. Paired with that, a pure-data fallback ensures a model timeout produces a deterministic output explicitly marked as degraded mode, rather than an empty string the next stage will misread as confidence. A single-owner lease sits on every shared external endpoint, the cure for the duplicate-consumer incident that ate one of my Sunday afternoons. The cheapest guard was the last to arrive: a one-line synthetic canary every agent has to produce a known correct response to before any real work begins, so a credentials rotation or silent backend failure trips an alert before downstream stages have generated artifacts against garbage.

None of these guards is novel. They are textbook stability patterns at a new boundary: the seam between the LLM agent and the rest of the system, which most of the existing agent literature still treats as a solved problem.

The 20% you don’t see, and when not to do this

Here is the part the demo videos leave out. Even when the pipeline works, the human time per stage does not go to zero.

Human review time per ticket across five pipeline stages: code review 60-180 min, automation review and flaky-fix loop 30-90 min, ticket architecture and sequencing 30-60 min, test data and environment 15-30 min, requirements review 20-30 min. Net: the human still spends 20-30% of the original effort, almost all of it reviewing rather than creating.

Net of all that, the human still spends twenty to thirty percent of the original effort, almost all of it reviewing rather than creating. The pipeline saves seventy to eighty percent, not ninety-eight. The trap is budgeting for the two percent you do not save.

When does this kind of pipeline make sense? In my experience, when the Figma is richly annotated and acceptance criteria are clear up front; when there is review capacity to absorb the work the pipeline shifts onto humans; when the stack is well represented in the training data; and when the feature is net-new rather than a deep edit of legacy code. When does it not? When the design lives on a whiteboard. When the integration touches old code with hidden contracts. When the path is regulated or safety-critical. When there is no senior reviewer who can hold the line. When the work is exploratory and writing the spec is the actual point of the exercise.

Teams I have seen succeed with agentic pipelines budget for the rework explicitly, staff the review queue and treat the saved hours as capacity for harder problems rather than headcount they can release. Teams I have seen struggle did the opposite: declared victory at the demo and quietly accumulated a backlog of half-trusted features the next quarter had to clean up.

The right unit of measurement is not how much the pipeline generates. It is how much of what it generates a human still has to touch before you would ship it. Call it the 80/20 rework rule: measure the rework, not the generation. The teams that get the rework number right are the ones whose AI investments compound. The teams that stop counting at the headline percentage are the ones that own the cleanup six months later.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Port has rolled out Port AI Builder, a vibe coding platform designed for software development and platform engineering teams.

Announced July 14, Port AI Builder lets teams create and run agentic workflows in natural language, with built-in human-in-the-loop review and approval. The platform lets organizations apply AI agents across the SDLC (software development life cycle), drawing on domain skills spanning site reliability engineering, devops, architecture, security, AI governance, data modeling, and UX, while maintaining governance and visibility, the company said. Port AI Builder is available through free and paid subscriptions.

Port AI Builder works on top of Port’s Agentic SDLC Platform, which provides the context lake, workflow orchestration, agent management, and governance that enterprises need to operationalize AI SDLC, according to the company. The new AI Builder lets teams build production-grade workflows in minutes, for use cases such as autonomous resolution, AI cost management, and engineering performance tracking, without losing control, Port said.

Oracle on Tuesday expanded its AI Agent Studio for Fusion Applications with new pro-code development tools, including a CLI-based capability called AI Studio Skill, allowing developers to build agentic applications using familiar environments such as VS Code, Codex, and Claude Code.

The AI Studio Skill is the CLI that provides the Fusion-specific context and tooling that AI coding assistants need to build Fusion-native applications. It provides access to the project structure, APIs, templates, validation, packaging, and deployment workflows required for Fusion Agentic Applications, Natalia Rachelson, SVP of product for Fusion Applications at Oracle, told InfoWorld.

“Think of it as Oracle’s development harness for popular AI coding assistants. Developers can use models like Codex or Claude Code to generate code, while the AI Studio Skill connects those models to Oracle AI Agent Studio and the Fusion runtime,” Rachelson said.

Familiar tools and workflows to simplify development

The access to familiar IDEs and harnesses, according to analysts, will make it easier for developers to build and maintain agentic applications for business workflows.

“The AI Studio Skill provides developers a way to build Fusion agents like a new software function versus configuring them like application extensions,” said Scott Bickley, advisory fellow at Info-Tech Research Group.

“Enterprise developers expect source control, code review, repeatable deployments, testing or debugging, and integration into their existing toolchains. Connecting the various IDEs and code assist products will make it easier to build, validate, and maintain agentic applications using already familiar tools and processes. This ostensibly will result in agents that are easier to maintain, govern, and align with enterprise development practices,” Bickley added.

For Robert Kramer, managing partner at KramerERP, the move is likely to drive more adoption of the Studio itself: “Oracle is meeting developers where they already work and making Fusion a more attractive place to build agentic applications.”

Native runtime could aid governance in production deployments

However, the CLI and IDE integrations, for Bickley, extend beyond developer productivity into tackling the governance and execution challenges that often prevent AI prototypes from reaching production.

“One of the most painful barriers to production AI is that many prototypes are built outside the enterprise systems where identity, permissions, workflow approvals, and overall system governance are already built in,” Bickley said.

In contrast, the integrations will allow enterprises to run agentic applications from inside Oracle’s platform, leveraging existing business context, identity, approvals, and governance rather than recreating those capabilities through external orchestration layers when moving them into production, Bickley added.

That shift, the analyst further added, will prove beneficial for CIOs because it will accelerate business outcomes while operating within a trusted environment.

Governance, observability, and lifecycle management matter more to CIOs after agentic applications move into production, Kramer echoed.

Governance gains come with strategic trade-offs

The approach of building and running agentic applications natively inside Oracle Fusion, though, is not without trade-offs, analysts cautioned.

CIOs should pay close attention to vendor lock-in as more business processes become agentic, Bickley pointed out.

“In the case of Oracle Fusion, ensure the ATLAS framework provides an accurate validation layer at a low cost of overhead. Consider the levers that Oracle may avail itself of contractually or commercially in the future,” Bickley said.

“ROI should be modeled against a progressive monetization schema as AI agents operate upon a consumption-based infrastructure.  As such, ensure provisions limiting cost overlays and uplifts are agreed upon prior to locking in,” Bickley added.

These considerations, the analyst further added, are becoming increasingly relevant because most enterprise software vendors, including the likes of SAP and ServiceNow, are introducing offerings and features to become the runtime and orchestration layer for enterprise AI.

Earlier in May, SAP expanded its AI strategy with the Autonomous Enterprise vision, introducing a unified Business AI Platform, Joule Studio 2.0, and AI Agent Hub to let enterprises build, govern, and run AI agents within a managed runtime.

In June, ServiceNow expanded its AI transformation by adding new features to its Context Engine and AI Control Tower, in order to better embed governance, enterprise context, and observability into AI workflows across enterprise systems.

During the same month, Salesforce, via its Informatica acquisition, added features to tie AI agents more closely to trusted enterprise data and operational workflows.

For developers and enterprises willing to try out the new CLI-based experience, it can be accessed from within the Studio without any additional cost, Oracle said.

The company is also adding a public GitHub repository that it said will provide templates, starter projects, sample applications, reusable assets, and reference architectures to help developers build and validate agentic applications faster.

Visual Studio Code 1.128, the most recent edition of Microsoft’s code editor, adds support for multi-chat agent sessions using Anthropic Claude agents.

Introduced July 8, VS Code 1.28 can be downloaded for Windows, Linux, or Mac from code.visualstudio.com.

With VS Code 1.28, multi-chat agent sessions now support using Anthropic Claude agents. With multiple chats, a session can contain related chats, allowing users to compare approaches, branch from an earlier turn, and run work in parallel. Users can add chats, fork a chat from an existing turn, switch between peer chats, and send turns concurrently. Each chat keeps its own history, title, and model selection, and restores with the parent session after restart, Microsoft said.

VS Code 1.28 also makes Copilot Vision generally available. With Copilot Vision, VS Code users can attach images and PDFs by pasting them into chat, dragging and dropping them, or using the context menu. Images also may be read by the agent via a tool call, Microsoft said.

Also in VS Code 1.28:

• Quick chats allow users to ask a question in the Agents window without opening a workspace first.
• VS Code can contribute OS-level keyboard shortcuts that take effect even if VS Code is not in focus. Users can add systemWide to a keybinding definition in keybindings.json to make it OS-level.
• Developers can configure a location for browser tabs to open via a new setting, workbench.browser.newTabPlacement. The setting provides three options: to open browser tabs in the active editor group, in a dedicated group to the side, or in a dedicated auxiliary window.
• VS Code can contribute OS-level keyboard shortcuts. These shortcuts take effect even if VS Code is not in focus.
• Administrators can configure where GitHub Copilot sends OpenTelemetry (OTel) data, allowing organizations to enforce telemetry flows to an approved collector without each developer setting OTEL_* environment variables. The managed configuration applies to both the Copilot Chat extension and the agent host process.

GitHub Copilot has introduced an interactive canvas that makes it easier to follow, review, and steer the actions of the upgrade agent as it modernizes .NET applications.

The GitHub Copilot upgrade agent assesses the application, generates a structured upgrade plan, creates implementation tasks, and executes the work, according to a July 9 bulletin from Microsoft. Now developers can follow that workflow in the GitHub Copilot app through an interactive upgrade canvas. The upgrade canvas provides a live view of the modernization workflow as it unfolds, Microsoft said.

This agent upgrade agent starts by assessing the .NET application and identifying what needs to change:

• What version of .NET is this application targeting?
• Which NuGet packages need to be updated?
• Are there breaking API changes?
• Which projects can be upgraded independently?
• What should happen first?

From this point, the agent generates a structured upgrade plan and breaks the work into actionable implementation tasks. While the GitHub Copilot app provides the interactive upgrade canvas, GitHub Copilot upgrade also is available in the following tools:

• Visual Studio – Built directly into Visual Studio. Right-click a solution or project in Solution Explorer and select Modernize to start a .NET upgrade.
• Visual Studio Code – Install the GitHub Copilot upgrade extension, select the Upgrade agent from the agent picker dropdown menu, and prompt the agent to modernize your .NET application.
• GitHub Copilot CLI – Install the GitHub Copilot upgrade plugin to assess, plan, and execute .NET upgrades directly from the terminal.

Developers can get started with GitHub Copilot and the GitHub Copilot upgrade agent by visiting the GitHub Copilot upgrade marketplace.

Microsoft has been pushing hard to make Visual Studio Code a major way to consume its AI services, mostly in the form of GitHub Copilot. GitHub Copilot’s deep integration with VS Code brings many conveniences — inline autocomplete, for instance — but it’s frustrating for those, like me, who would rather use another model provider, or even a locally hosted LLM, for those functions.

Visual Studio Code 1.122 introduced a new feature, “Use BYOK [Bring Your Own Key] without a GitHub sign-in,” that allows you to “use chat, tools, and MCP servers in air-gapped or restricted environments where GitHub sign-in isn’t possible.” More importantly, it “enables fully offline workflows with local models like Ollama.”

In other words, you can now use locally hosted LLMs for chat, tools, and Model Context Protocol servers inside Visual Studio Code. The one thing you still can’t do is use a local LLM for inline and next-edit suggestions — at least, not without additional tooling.

Choosing a model for BYOK mode

If you want to use a local LLM with VS Code’s bring-your-own-model system, the first thing you need is a way to host the model. VS Code lacks a model-hosting mechanism of its own, although it’s conceivable that a VS Code extension may offer something like that in the future. That said, hosting models is complicated enough that a dedicated app is really needed for the job.

One easy way to host models is via a product like LM Studio, a convenient GUI for standing up, serving, and managing LLMs on one’s own hardware. The model host does not have to be the same system you run VS Code on, either. It can be on a server box you control, or on a cloud instance.

The choice of model is also important. Many models are powerful but won’t run well on commodity hardware because they’re simply too big. A good rule of thumb is to choose a model that fits into existing VRAM, along with the memory needed for a sizable token context (the more, the better). Also, the model should be suited to coding and development work. Some models in this vein that fit comfortably into 8GB VRAM include:

• Gemma4 (effective 2 billion parameters version)
• Qwen3.5 9B
• Codestral 22B v.0.1 (proprietary license)

Setting up BYOK mode in VS Code

Once you have a model up and running, you can integrate it with Visual Studio Code. If you’ve disabled VS Code’s AI features, you will need to turn them on. Make sure the setting chat.disableAIFeatures is turned off. You can find it in Settings | Chat | Miscellaneous.

Third-party language models are managed through Visual Studio Code’s language model list. Press Ctrl-Shift-P and type Manage Language Models to open the list of existing language models.

First you will see a list of the built-in models, which are all externally hosted. To add a new model, select Add Models at the top right and select Custom Endpoint.

You’ll then get a series of prompts:

• Group Name: This is “Custom Endpoint” by default, but you can choose any name you want. The name is strictly for organizing the model list and doesn’t affect things like model recognition or connectivity.
• API Key: If you’ve configured LM Studio to use an API key for serving models, provide it here. If you’re hosting the model locally and you haven’t explicitly set up API keys, you can leave this blank.
• API Type: The options here are Chat Completions, Responses, and Messages. Most of the time you’ll want to use Responses, as it’s the most general-purpose option of the three.

Once you finish providing those answers, you’ll be dropped into a modal editor for a JSON file that holds the details about the endpoint you’re configuring.

You’ll need to provide a few more details by typing them into the labeled fields:

• id: A text field that uniquely identifies this particular entry. The choice of ID is pretty much arbitrary; if you’re using only a single model, the ID could be the model name.
• name: The name of the model that is used to identify it on the model server. In LM Studio, you can get this name by clicking on My Models in the main interface, then selecting the three-dot icon for the model in question and clicking Copy Default Identifier. For Qwen 2.5, for instance, name might be something like qwen2.5-coder-7b-instruct.
• url: The URL to the server’s endpoint. On LM Studio, this defaults to something like http://127.0.0.1:1234/v1. The /v1 at the end is important because that endpoint is used for autodiscovery of models and their capabilities.

The other fields generally don’t need editing. Most models have tool calling functionality. If you know for a fact that the model you’re using doesn’t have vision support, then set vision to false.

Once you have these fields filled in, you can close the modal editor to save the changes. If you reload the Manage Language Models page, you’ll now see your new endpoint:

You should now be able to launch the chat window and use the defined model for conversation and utilities:

One current, and major, limitation of Visual Studio Code’s BYOK functionality is that it only works for chat and utility tasks. It doesn’t allow you to use a local model for inline suggestions or code completions. The only way to take advantage of local models for expanded functionality with VS Code is to use a third-party tool like Continue.

It isn’t clear if Microsoft will eventually lift this restriction. GitHub Copilot integration in VS Code is a large part of how Copilot as a service reaches its target audience. For the time being, you can certainly use third-party and local models for a significant part of your AI-assisted development work in VS Code, and you can close the functionality gap with additional tooling.

AI coding agents can tend to isolate research, running experiments and generating ideas that are then forgotten when context windows reset. This can waste tokens, as models then repeat the same mistakes and hit the same dead ends.

But new research argues that it’s not the model itself, but the overarching ‘tree,’ that needs tweaking. To that end, data scientists from the Gaoling School of Artificial Intelligence, Renmin University of China, and Microsoft Research have introduced Arbor, a “persistent hypothesis tree” that helps agents remember and refine learnings over long research sessions.

A long-lived coordinator manages research strategy across the tree, while short-lived executors spin up isolated worktrees to test different hypotheses. As results come back, the tree updates, narrowing and refining throughout experimentation.

In practical tests, this technique delivered more than two-fold performance gains over standard AI coding agents across real-world engineering tasks, for the same budget.

This is because, said Mahmoud Ramin, a research director at Info-Tech Research Group, “Arbor accumulates information over time and allows agents to build upon prior discoveries just as humans do, through learning, adaptation, and eventually building upon what they have learned in the past.”

How Arbor grows

Arbor’s builders argued that longer execution on its own does not guarantee research progress. The challenge is maintaining a state that turns many individual attempts into “cumulative hypothesis refinement.”

Further, progress should not depend on human overseers regularly stepping in to dictate logical next steps or interpret the meaning of previous trials, they noted. To be truly autonomous, agentic research frameworks must maintain connections between experiments, data, results, and failures over time.

Arbor is built to fulfill three system requirements. First, it must be able to branch as sub-trees test out competing hypotheses that are all potentially plausible. At the same time, unrestricted branching can degenerate the whole framework, so that must be controlled to remain organized. The researchers call this “branching with coherence.”

Second, the infrastructure must separate local execution from overarching strategy. Testing out single hypotheses requires short-horizon tasks like editing, debugging, and evaluation. But these should not “obscure” the larger tree making decisions based on evidence gathered across the whole run.

Finally, the systems must be able to distinguish exploratory improvement from verified improvement. This prevents AI from overfitting during trial-and-error instead of iteratively learning from underlying patterns.

Persistence is at the core; the tree links hypotheses and ideas, the code or configuration artifacts used to test them, experimental evidence (results, metrics), and distilled insights (such as “this data filter helped, but this learning rate scheduler didn’t”).

Once a project kicks off, shorter-execution work trees run code, log their work, and collect metrics. The long-lived coordinator above them serves as the de-facto head of research, keeping an eye on the process, updating nodes, selecting “promising leaves,” pruning or merging branches, propagating reusable lessons, and deciding which hypotheses to pursue next.

“The tree therefore acts as the operational research state of the system,” Arbor’s builders wrote. “It is simultaneously the search frontier, the memory of past attempts, and the audit trail for verified artifact improvement.”

Outperforming Codex and Claude on new data

To test how well this process works, the researchers evaluated Arbor in an autonomous optimization (AO) setting: the agent was given an initial research artifact (a data pipeline, harness, or training script) and was tasked with improving its “held-out performance” through iterative experimentation, without human steering. Held-out performance is a machine learning (ML) metric that evaluates how well models are able to generalize on data they haven’t seen before.

The tree-based architecture was tested on several real research tasks across model training (its ability to improve training recipes and hyperparameters), harness engineering (how well it can upgrade evaluation or training harnesses), and data synthesis (its capacity to generate better data for training or evals).

Ultimately, Arbor outperformed the average held-out gains of Codex and Claude Code by 2.5x, for the same resource budget.

The takeaway, said the researchers: Keeping a structured, evolving hypothesis tree yields greater performance improvements than running the same models as ‘memoryless’ coding agents.

Arbor’s most innovative feature is its ability to maintain the agent’s memory and retain relevant data from prior attempts and hypotheses, Info-Tech’s Ramin pointed out, and, he said, “the next step for autonomous agents may be accumulating evidence over time.”

However, this does raise concerns about the auditability of robust research environments at a large scale, he noted. “As autonomous agents become more capable of performing work without human operators overseeing them, enterprises will need transparency into how and/or why an agent took a specific action or reached a certain conclusion.”