Reading

In 1951, Cambridge University’s computer went out of action for six months. Physiologist Andrew Huxley was forced to crank a hand-operated mechanical calculator, spending over three weeks solving equations he and Alan Hodgkin had just established—equations describing the action potentials of squid nerve cells. To make the curve fit experimental data, they found they had to raise a certain variable to the fourth power. At the time, they did not know why; they only knew that simpler versions (such as the third power) did not fit well enough, while higher powers might fit slightly better but were not worth the extra complexity. They cautiously proposed a hypothesis: perhaps four charged particles on the membrane must be in place simultaneously for the gate to open.

Decades later, another team found the structure of the relevant potassium ion channel protein and discovered that it indeed consists of four identical subunits arranged around a central pore. The model fitted the data in 1951, yet it helped predict the structure of a protein it had never been fitted to.

In this guest article published in November 2026, Jakob Macke, Daniel Gedon, and Stefan Wahl of the ELLIS Institute Tübingen Branch and the University of Tübingen use this story as a starting point to propose a core argument about AI-assisted scientific modeling: simply knowing that the fourth power fits the data is not enough; what matters is knowing that simpler versions do not work. An AI system that merely hands you a model can give you an answer, but it cannot give you understanding.

They divide scientific modeling into three steps: building the model (deciding the shape and components of the equation), constraining the model (tuning parameters to fit measured data), and interpreting the model (asking what the model says about the real system). The Hodgkin-Huxley four-particle hypothesis held up precisely because they ruled out lower-power alternatives. If the third power could also fit the data, there would be no reason to believe the gating mechanism involved multiple moving parts.

The article argues that AI has made the most progress in the constraint step. Traditional methods provide only one set of optimal parameters, hiding other combinations that could also fit the data. Simulation-Based Inference (SBI), through extensive random sampling and neural network training, returns a complete probability distribution of parameters, allowing researchers to see which parameters are tightly constrained by data, which remain ambiguous, and where more experiments are needed. This method has been applied to the Hodgkin-Huxley model itself, as well as to neutron star collision localization, cosmology, and structural biology.

In the building step, LLM agents can now write code to generate candidate models, run them, constrain parameters, compare outputs, and modify equation forms in a loop until the fit is good enough. However, the article points out a key issue: running an agent twice on the same data may return two different but equally good models. Returning only one of them is like returning only one set of optimal parameters—it hides other possibilities. Therefore, the authors advocate treating model building similarly to model constraining: requiring the AI system to return the range of all models that can reasonably explain the data, rather than a single best fit.

When enterprise AI Agents need access to data lakes, the most common practice is for each Agent to embed its own SQL generation logic, schema knowledge, and connection handling. When datasets change, every Agent must be patched individually; permissions are scattered with no unified audit point; onboarding a new table typically requires days of custom development. Under the pressure of managing thousands of datasets while multiple teams build their own AI assistants, the engineering team supporting Amazon’s North America Sort Center (NASC) network chose a different path: centralizing data access capabilities into a single stateless MCP server, letting Agents focus solely on reasoning and orchestration without worrying about how underlying data is accessed.

The core design decision of this server is to decouple the tool layer from the agent layer. Agents evolve rapidly, but data access patterns should outlive any single Agent implementation. The specific approach is as follows: each table corresponds to a JSON metadata file recording the database service name, table name, business description, column-level semantics (including type, natural language explanation, and sample values), load type, and refresh frequency. After this file is picked up by the pipeline, vector embeddings are generated using Amazon Titan Text Embeddings and indexed into Amazon Bedrock Knowledge Bases. Once indexing is complete, all connected Agents can discover and query that table without manually rebuilding indexes or restarting the server.

There is an easily overlooked but actually critical field in the metadata file: business_description_for_the_table. It does not just write the business meaning of the table, but also carries engine-specific query hints. For example, the example in the text writes:

In Athena SQL, always use date() to wrap string literals when comparing against timestamp columns.

Such hints directly reduce the number of validation failures after SQL generation. Column-level sample values are equally important—if the Agent sees that the sample value for warehouse_id is FC-EAST-07 rather than East region facility, the generated WHERE clause will use the correct format.

The architecture is divided into four layers, each independently scalable: the client layer handles authentication and session state (Amazon Cognito validates JWTs, DynamoDB stores conversation history); the MCP server layer performs query analysis, tool selection, and result orchestration (FastMCP framework, driven by Amazon Bedrock); the tool layer connects to Athena and Redshift to execute SQL and to Knowledge Bases for semantic retrieval; the knowledge base refresh layer is responsible for discovering and indexing metadata files. Fargate tasks are stateless, with session state persisted in DynamoDB, so tasks can be replaced or scaled at any time without losing context.

The team also introduced an optional context mapping mechanism: specifying which tables a particular application should focus on. When context limits the table scope, the MCP server searches only those tables in the metadata catalog, reducing noise and improving SQL generation accuracy, while keeping end-to-end latency within the 15 to 20 seconds range tested by the team. When no context is specified, the Agent searches all indexed tables.

When building agent systems, a persistent question arises: how should a given user request be classified? In a blog post published in November 2026, the Amazon Quick team offered their answer—not by providing a single definitive solution, but by introducing a shared vocabulary that allows different interpretations to coexist and switch seamlessly.

They break down agentic work into four fundamental questions: When (what triggers the work), What (the task content), Who (who performs it), and How (how it is executed). Triggers address both When and What; agents answer Who; and capabilities answer How. While this decomposition is straightforward, its value lies in enabling different implementation paths for the same request to exist not as mutually exclusive competitors, but as varying degrees of confidence within the same framework.

A 'confidence contract' defines the balance between the autonomy an agent retains and the extent to which the user pre-defines the process. The Amazon Quick team illustrated this with a concrete example: a user says, 'Monitor my Slack channel and send me a daily summary.' This request can be implemented in at least three ways: first, a scheduled task with a one-line instruction letting the agent decide how to proceed; second, a skill packaging explicit formatting rules and channel priorities; third, a workflow declaring deterministic steps and error handling. All three produce a daily summary; the difference lies solely in the latitude granted to the agent.

This distinction yields a practical inference: a user request like 'I want an agent that monitors Slack and sends a daily summary' usually does not require creating a new agent or workflow, but rather adding a trigger to an existing agent. Based on this, the Amazon Quick team merges chat, scheduled, and so-called 'autonomous' agents into a single actor—one you can converse with, schedule, and which can orchestrate and inspect its own past work.

Regarding the relationship between skills and workflows, they propose two dynamic concepts: crystallization and dissolution. A well-understood skill can tighten into a workflow; a workflow frequently encountering edge cases can loosen back into a skill. This transition is driven by their continuous learning framework, with specific mechanisms detailed in subsequent articles.

Important caveats apply: this is an internal vendor-specific vocabulary designed to unify architectural discussions across their own product line. The article provides no evidence of independent adoption, nor controlled experiments demonstrating that this classification actually reduces builder confusion. Its current value remains at the level of 'a clear attribution argument'—the authors explain why a shared vocabulary is needed, how it is structured, and how it changes the classification of specific requests. For readers building agent systems, this four-question decomposition and the concept of confidence contracts offer a directly usable thinking framework, but treating it as an industry standard is premature.

A notable design choice for Greenlight Financial’s security operations agent, Luna, is that it does not rely on more powerful models or additional tools to improve accuracy; instead, it relies on memory.

Luna is a tiered multi-agent system where Tier 1 handles the triage of routine alerts, while Tier 2 manages complex cases requiring multi-step reasoning. With Tier 1 operating alone, the autonomous resolution rate plateaued at 83%. Greenlight reports that adding the memory layer pushed this figure above 90%.

The memory layer consists of two parts. The first is short-term memory with a 30-day rolling window: when a new alert arrives, Luna checks whether this pattern occurred in the past 30 days, how it was adjudicated, and whether it should be allowed through. Greenlight provided a specific example—an infrastructure role executes planned maintenance every Tuesday at 3 AM. A system without memory would re-flag this behavior weekly, whereas a system with memory learns after the first resolution that this is expected behavior and automatically adds it to the allowlist.

The second part is long-term memory, which stores semantic preferences and resolution templates beyond the 30-day window. For instance, cards originating from a specific dark web source have a 73% false-positive rate, so deduplication is prioritized; or resolution templates encoded for recurring case types.

What truly drives the accuracy increase from 83% to over 90% is the case-learning pipeline connecting these two memory components. An AWS Lambda function captures each case resolution result, while DynamoDB stores resolution patterns and deduplicates them. The key rule is: when Luna resolves a case in the same way three times, it records this as a confirmed pattern. Another Lambda function then processes these newly learned insights into actionable context for supervisors to consume during inference. This feedback loop allows Tier 1’s first-pass success rate to continuously improve.

Greenlight lists this approach as one of five lessons learned, calling it 'memory compounding': every resolved case teaches Luna something—a new allowlisted pattern, a confirmed false-positive source, or a resolution template. After six months of operation, Luna has accumulated organizational knowledge equivalent to the experience a new human analyst would need months to build.

It is important to note that all these figures come from Greenlight’s self-reported production measurements, published by AWS as the platform provider. The article does not disclose the denominator (whether the total volume of cases changed concurrently), does not explain selection effects (whether complex cases still relied on humans), and lacks a before-and-after experimental design. The reported improvement from 83% to over 90% combines the addition of Tier 2 with the contribution of the memory layer, making it impossible to attribute the gain solely to the memory mechanism itself.

The Anthropic research team analyzed 207,049 research sessions conducted between August and September 2026, covering 34 disciplines and 7,262 research tasks, reaching a counterintuitive conclusion: scientists use AI where it is most capable, not where they believe it is most important. In surveys, researchers ranked idea generation and hypothesis formulation as the most critical tasks for producing impactful results, with data collection ranking second. However, in actual usage, data analysis accounted for approximately one-third of Claude sessions and nearly half of Claude Code sessions, while idea generation comprised only 4.2% of Claude sessions and 2.1% of Claude Code sessions.

This usage pattern is not random; it closely follows AI's theoretical capabilities. The research team constructed capability scores for each task using a Bradley-Terry model—the same methodology used for chess Elo ratings—by having language models compare pairs of task steps to determine which AI could perform better, then aggregating these into task-level scores. The results showed that the top 20% of tasks by capability score (such as data visualization and statistical testing) received two to four times more AI usage than the time researchers spent on them would predict. Conversely, the bottom 20% of tasks (such as purifying reaction mixtures or participant observation) saw almost no usage. Capability scores were highly correlated with three factors: whether the task was suitable for reinforcement learning (i.e., whether it could be repeatedly attempted in a computational environment with immediate feedback), whether the work was predominantly cognitive rather than physical or interpersonal, and whether regulatory constraints limited AI use. In short, scientists appear to use AI where it works best.

Based on these findings, the report constructed three acceleration scenarios. With widespread adoption of current capabilities, output in some fields could double (approximately 2x in computer science and statistics). If AI automated 75% of non-physical steps, computer science could see an 8x increase, but experimental sciences would be limited to 2–3x due to physical bottlenecks. If all non-physical steps were automated, computer science and statistics could theoretically reach 15–16x acceleration, while chemistry, biology, and other fields would remain constrained by approximately 40% of physical time. These figures are model projections rather than predictions, relying on explicit assumptions: an AI cost of $30 per hour compared to a researcher's $95 per hour, and bottleneck-shifting effects caused by task complementarity.

The report also documented that specialized tools are narrowing this gap. On Claude Science—a dedicated interface connecting multiple research databases—idea generation and hypothesis formulation accounted for 8% of sessions, approaching the share of researcher time and doubling the share seen on general-purpose Claude. In biomedical fields, over 80% of tasks on Claude Science required doctoral-level training, and more than 70% were executed with high autonomy, significantly higher than the 23.7% on Claude and 64.1% on Claude Code. This suggests that specialized infrastructure is partially breaking through the capability boundaries of general AI tools. However, caveats apply: the 528 survey respondents came from a group actively applying for AI research credits, likely representing heavier AI users than the average scientist; capability scores were generated by language models and have not been independently verified; and the acceleration scenarios assumed full diffusion, whereas real-world technology adoption typically lags behind capability.

In a video published in November 2026, c't magazine reporter Jan-Keno Janssen released a series of hardware benchmarks for local large language models, with the core finding being that the data transfer rate of memory—not the floating-point compute power of the GPU—determines token generation speed. Using the standard llama.cpp tool to test Qwen 3.8-27B (Q4_K_M quantization), the RTX 4090 achieved 51.1 tokens per second, whereas running CPU inference on the same machine using only DDR5-5200 memory resulted in an output so slow it was visibly character-by-character—a difference of about 15 times. He explicitly pointed out that DDR5-5200 has a bandwidth more than 12 times slower than the 4090's GDDR6X, a ratio that largely corresponds to the difference in inference speeds.

This mechanism explains the practical trade-offs different hardware platforms face in coding agent workflows. The Mac Studio M5 Ultra (with 256GB of unified memory) is nearly on par with the RTX 4090 during the token generation phase, but achieves less than one-third of its speed during prompt processing (reading long code or documents): while the 4090 reads about 4,000 tokens of video text in just over a second, the Mac takes about 4 seconds. This makes little difference for pure chat, but coding agents need to repeatedly read codebases and documentation, meaning bottlenecks fall on bandwidth and compute power respectively. Although the AMD RX 9070 XT (€920, 16GB VRAM) ran at 34.4 tokens per second, the weights for Qwen 3.8-27B plus context almost completely filled the VRAM, leaving only about 8K tokens of usable context. It cannot simultaneously support image recognition and the 60K+ context required for coding agents—meaning it can run benchmarks but struggles with actual workloads.

Janssen's practical rule is: when choosing hardware, look at memory bandwidth first, then capacity. GPUs with 24GB or 32GB of VRAM can hold both model weights and sufficient context; unified memory systems should have at least 48GB to leave room for OS and other software overhead. The Intel Arc Pro B70 (32GB, currently priced above €1,700) generates at about half the speed of the 4090, but offers ample capacity and supports ComfyUI image generation. The AMD Strix Halo (128GB unified memory, under €4,000) has a raw generation speed of only 13.3 tokens per second, but enables speculative decoding to boost performance to over 40 in code generation scenarios, and even exceeds 100 in code reproduction scenarios. All data are self-tested by the author using the llama-bench tool from llama.cpp under standard parameters, without independent replication.

Resource configuration for agent simulations presents a fundamental contradiction: all code within the sandbox is generated by large language models, making the execution pattern impossible to determine in advance. Throughout a sandbox's lifecycle, it often experiences periods of silence while waiting for model responses, immediately followed by instantaneous spikes such as grep commands or file traversals. The height of these spikes depends on exactly what code the model generates, which is unknowable at the time of configuration.

AI data company Snorkel previously estimated CPU and memory quotas for each sandbox, resulting in a lose-lose situation: tasks would crash midway due to insufficient quotas, invalidating the entire run; conversely, abundant resources led to idleness and inefficient spending. Rustem Feyzkhanov, Snorkel's Senior Manager of AI Platform, stated that they needed to support various tasks from domain experts and agents without over-provisioning.

Modal's elastic bursting mechanism changed this landscape. Sandboxes specify a baseline resource amount during configuration but can elastically expand CPU or memory on demand during runtime. Billing rules take the higher of actual usage or requested amount. This means Snorkel can lower initial requests—because bursting capabilities cover the spikes—without needing to reserve margins for worst-case scenarios. Feyzkhanov stated that this change reduced their total sandbox bill by approximately 20%.

Currently, about 10-15% of Snorkel's sandboxes have enabled the bursting feature, and the team remains in the early adoption phase. However, this mechanism solves more than just cost issues. When resource quotas no longer need to reserve margins for unpredictable spikes, the reliability of evaluation results also improves—runs failing due to insufficient resources decrease, and these failures themselves would otherwise pollute benchmark test data.

Snorkel runs millions of agent simulations monthly, creating tens of thousands of sandboxes per hour during peak times. Evaluation environments need to be as close as possible to the working conditions agents will actually face: ML agents require GPUs to train models, while infrastructure agents may need access to a complete Linux kernel. If the environment is not realistic, it becomes impossible to distinguish whether an agent failed due to missing tools or due to its own capability limitations. Feyzkhanov said that Modal's sandboxes allow them to reproduce complex systems ranging from multi-container infrastructure to GPU deep learning environments across millions of simulations.