AlphaGenome 2 narrows the search from DNA to the cells that matter

AlphaGenome 2 finds the cellular target

A DNA change can look very different depending on which cell you examine. AlphaGenome 2 aims to help researchers choose where to look, before they commit to the next laboratory experiment.

Our main story today is Google DeepMind's AlphaGenome 2, and how more precise predictions could help scientists connect a genetic change to the cells affected by it. Announced on 11 November, the model predicts effects for particular cell types and states, rather than averaging across an entire tissue.

That extra detail is the interesting part. An average can describe the overall pattern while making a more local effect harder to see. If a genetic change has an important effect in one kind of cell, knowing the tissue alone leaves a researcher with another question to answer. Cell-specific predictions give them a more focused starting point.

There's a useful way to picture the research decision. A scientist has a candidate DNA variation and wants to understand its role. They need to decide which cells to study and which predicted effect to test. A model that helps with both decisions could make that experiment more informative. The value is in the quality of the question that reaches the laboratory.

DeepMind reports that, on the TenK10K immune-cell dataset, AlphaGenome 2 identified 30 per cent of causal variants. The previous model, fine-tuned on single-cell data, identified 16 per cent. That's a substantial improvement on this evaluation, and the comparison is with a predecessor already adapted to single-cell information.

The cell-specific approach also gives that result a practical shape. A researcher can prioritise a variant together with the cell type in which its effect is predicted. That pairing helps turn a broad genetic lead into something more concrete to investigate. For an organisation choosing among possible experiments, a clearer target could be valuable even before any new treatment enters the picture.

The example involving inflammatory bowel disease makes this easier to understand. AlphaGenome 2 computationally reproduced aspects of an established finding involving the ETS2 gene in gut macrophages, a type of immune cell. Nature sought independent comment from the researcher who led the original experimental work.

The useful connection here is between a prediction and an existing experimental finding. The model points towards a gene and a cellular setting that researchers have already investigated. That gives scientists a tangible example of what this approach can pick up, and a basis for asking where else it might help them choose a productive experiment.

My take is that better experimental targeting is the strongest reason for research organisations to pay attention. Laboratory work still has to establish what happens when a predicted mechanism is tested. But narrowing the candidate list, and identifying the cells to examine, could make the next round of that work more focused.

Access is already open through an API for non-commercial research, with commercial research in private preview. The models aren't validated or approved for diagnosis or clinical use, and broad prospective validation remains ahead. That puts the immediate opportunity squarely in research: using a more detailed prediction to decide which biological question to test next.

AMD's new EPYC platforms ship

That takes us from choosing a laboratory experiment to the shorter news, starting with the computers doing the work.

AMD announced general availability of its sixth-generation EPYC server processors on 10 November. These are Zen 6-based processors using the SP7 platform, and AMD says systems from server manufacturers are shipping. For organisations buying their own infrastructure, there's a new server option to assess now.

The cloud rollout has a different timetable. AMD identifies Microsoft's Azure HDv2 as a preview, while Oracle's OCI Compute E7 instances are forthcoming. A buyer considering an on-premises system and a developer waiting for a particular cloud instance are therefore looking at different stages of availability.

One of the more revealing parts of the launch is how AMD talks about AI agents. Its advertised agent-capacity comparisons estimate agent counts from available CPU threads. A thread is a unit of execution capacity, so counting threads provides a way to estimate how much work might run alongside other work.

For an agent application, though, the useful output is a completed task. AMD's footnotes identify models, memory, software and orchestration as factors in actual throughput. Orchestration is the software coordinating the steps and tools an agent uses. Those dependencies help explain why a processor's capacity and an application's completed work are different measurements.

This is also a reminder of where infrastructure spending can go. An AI service has CPU execution and data movement around its model calls. Organisations planning agent systems have reasons to examine that supporting infrastructure alongside their GPU requirements.

For a procurement decision, I'd want the comparison expressed in the work the organisation expects to run: how many tasks finish, how long they take, and the resources they consume. That connects a hardware choice to an operating cost people can understand. The launch's agents-per-watt figures are theoretical capacity estimates, so they don't supply that completed-work comparison.

The practical opening is a shipping on-premises platform. Buyers can assess it against their own workload, while keeping the Azure preview and forthcoming Oracle instances on their separate rollout schedules.

Grok Build's exposed apps

Making an internal app quickly is appealing. Publishing it can change who gets to see what's inside.

Security firm Claroc disclosed on 10 November that published Grok Build apps exposed internal business and personal information through discoverable sharing addresses, without requiring sign-in.

Claroc counted 35,578 apps accessible without sign-in among 37,571 live apps it checked. Separately, it estimated that roughly 650 to 800 contained private data. Those are two different groups: the larger number describes public accessibility, while the smaller estimate identifies apps containing information that raised privacy concerns.

The mechanism is straightforward. App hostnames can appear in passive-DNS indexes, which collect records of domain-name activity. A sharing address can therefore become discoverable beyond the people who originally received it. An unfamiliar, hard-to-guess link still needs access controls if the information behind it is meant to be private.

Publishing requires a creator to take action. Claroc found public-link access preselected in its test account; xAI said apps remain private until creators publish them. That places the important decision at the publishing step, where a person making a useful tool also decides who can reach it.

Ars Technica reported that 24 staff-built apps were removed after its enquiries. Claroc tested unauthorised writes only on its own two apps. Its wider findings establish a data-exposure problem; whether malicious outsiders accessed the information remains unknown.

For an organisation already using Grok Build, the useful response is to review published apps, their access settings and the authorisation protecting their data. Sign-in and authorisation answer related questions: who is this person, and what are they allowed to read or change? An internal-looking screen doesn't answer either one.

This is where fast app creation can create a gap in normal delivery work. The person building a tool may be concentrating on whether it performs the intended job. Publishing introduces a separate question about its audience. A tool containing business records can work exactly as its creator intended while making those records available too widely.

My concern is that organisations can gain speed in building these tools while leaving ownership of published access unclear. Making that responsibility part of the handover is a concrete way to preserve the benefit of quick app creation without leaving private records behind an open link.

Europe targets manipulative design

The choices a service puts in front of you are also getting closer attention from European lawmakers.

On 11 November, the European Commission adopted its proposal for a Digital Fairness Act alongside a Simplification Directive. The package seeks changes to EU consumer protection, including how digital services steer people's behaviour.

The proposal addresses dark patterns: interface choices that manipulate or obstruct a person's decision. It also covers addictive design, personalisation that exploits vulnerabilities, and misleading or obscure pricing practices. Those categories reach into the experience of using a service, including how options appear and how easily a person can act on them.

Some of the examples are especially familiar. Subscription-cancellation obstacles are in scope, along with unwanted conversion of trials into paid subscriptions and difficulty reaching a human customer-service representative. These are moments where the design of a service can affect a person's money, time or ability to resolve a problem.

The proposal gives digital businesses serving EU consumers something concrete to assess against their existing products. A subscription journey can be considered from the customer's side: how they enter, how the price is presented, what happens when a trial ends, and how they leave. Customer service belongs in that examination too, particularly when a person needs help beyond the interface.

For me, the significant shift is that consumer protection is paying closer attention to the route a person takes through a product. A disclosure can contain information while the surrounding experience makes a choice difficult to understand or carry out. Interface design is part of the commercial relationship.

This remains a legislative proposal. Final provisions, adoption and application dates depend on the legislative process, and it creates no new Australian rights. For people following the debate, the useful detail is the set of everyday problems being addressed. For product owners serving Europe, those specific journeys give them a much clearer basis for reviewing their design than a broad instruction to make it fair.

Qwen4-Max's limited preview

There's another model available to try, with an unusually important date attached to the access window.

Alibaba opened Qwen4-Max-Preview on 11 November through its developer Token Plan and listed it as active in Qwen Chat. The official chat catalogue specifies a one-million-token context window and support for text, images and video.

A context window is the amount of material a model can take into account at once. That large specification makes longer inputs an interesting area to explore. Dependable performance across a long task is a separate question for an evaluation, especially when useful details are spread throughout the material.

The preview runs from 10 am on 11 November until midnight at the end of 25 November, in the documented UTC-plus-eight time zone. Alibaba says the preview model will be retired afterwards. Anyone comparing it with an existing workflow has a defined window in which to do that work.

Access terms also shape what can be tried. The international Personal Edition requires a subscription and permits interactive coding or agent-tool use. Custom application backends and unattended batch calls are outside those terms. So the available route fits a developer working interactively with supported tools.

The plan's region is Singapore, while inference is global and involves cross-border data transfer. For a developer working with organisational material, that detail affects which inputs are appropriate for the evaluation. A region label on the plan doesn't confine all processing to that region.

I'd treat this as a chance to compare how another model handles the working material and tasks you already understand. The most informative result could be a specific strength or weakness in that workflow, rather than a broad ranking based on context size.

There is no established final-model release date in the available documentation. With retirement already specified for this preview, the durable output of an evaluation is what you learn about its behaviour. Any longer-term application plan needs an access arrangement that continues beyond 25 November.

Adobe's assistants work inside projects

For creative work, the interesting question is how much of an AI's output you can keep editing.

Adobe expanded Creative Agent-powered assistants across its desktop creative applications on 10 November. The assistants are beta features; examples in Premiere include applying effects and adjusting colour across a sequence.

That puts assistance within the project a creative professional is already working on. Applying an effect or making an adjustment can leave the work in a form the creator can inspect and refine. A native project retains the application's editing structure, which gives follow-up changes somewhere useful to happen.

Adobe also previewed local connections using MCP, the Model Context Protocol, for third-party agents. These would let external agents work with native Photoshop, Illustrator, Premiere and After Effects projects. That capability is scheduled for private beta in early 2027.

For a creative team making plans now, built-in beta assistants are the part available to evaluate. External-agent control is a later step, with a private-beta entry point rather than general access.

I think the native-file approach is the most promising detail. Creative work often involves adjusting an earlier choice, and editable output gives a person more room to do that. The useful evaluation is whether the assistant's changes leave the creator able to continue working comfortably in the project.

CoreWeave brings the database closer

There's a less visible part of running an AI application that's getting some attention too: its database.

CoreWeave made its managed PostgreSQL-compatible database generally available on 11 November. It runs inside customers' CoreWeave Kubernetes Service clusters, on CPU nodes, using CoreWeave storage. Kubernetes coordinates the applications and computing resources within those clusters.

For existing customers, this offers a way to keep application state beside their AI workloads. The alternative may involve running PostgreSQL themselves or maintaining a database connection across cloud providers.

The service includes managed failover, continuous backups and point-in-time recovery. Failover handles switching away from a failed database instance; point-in-time recovery allows restoration to an earlier point. Those are operational capabilities that application builders would otherwise need to arrange as part of running the database.

It also supports pgvector, which lets a PostgreSQL database store and search embeddings, the numerical representations used to compare related content. That means embeddings and ordinary application data can share a database.

The attraction for a developer already on CoreWeave is having fewer infrastructure boundaries to manage. Moving more of the application stack into the same provider also concentrates the dependency there. I'd weigh this around the operation of the whole application: who runs the database, how recovery works, and how closely its future is tied to the rest of the platform.

What Changes for You

If you keep copying useful AI output into another app so people can work on it, this is worth a look.

Anthropic launched Claude Sheets and Whiteboards in beta on 10 November, and made its former Dashboards product generally available as Claude Data. All three are offered on paid plans, across web, desktop and mobile.

Sheets lets people jointly edit spreadsheets with formulas and multiple tabs, with export to XLSX and CSV. Whiteboards provides shared space for developing ideas. Claude Data lets people query connected business data. Together, they give paid users more ways to keep a budget, planning board or dashboard editable inside Claude.

The difference is what happens after the first output. Someone can change an assumption in a shared spreadsheet, or develop an idea on a board, in the same working artefact. My interest is in that continuing collaboration: the output has somewhere to live while people work through it.

Sheets currently has basic spreadsheet functionality, so complex existing spreadsheet workflows may still need their current tools. Data work also requires an authorised connector.

Access depends on the organisation's settings. On Team plans, all three are enabled by default. On Enterprise, Sheets and Whiteboards are disabled by default, while Claude Data is scheduled to turn on by default on 19 November. Enterprise users therefore need their administrator's settings to line up with the work they want to do.

Claude Data's certified queries and live sharing remain in beta. There's a useful permission distinction in the sharing model: a viewer can see approved query results without gaining permission to run other queries through the owner's connection. That lets someone share an answer while keeping the underlying querying access narrower.

Claude Meetings is still coming soon. The available change is shared sheets, boards and data views, with enough continuity for colleagues to keep working on an output instead of treating every answer as a finished handoff.