# benchling Published articles for benchling. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Fragmentation to framework: Spec-first development at Benchling DevFeed: [Fragmentation to framework: Spec-first development at Benchling]() Original publisher: [Read original article]() Author: Eli Levine Published: 2026-02-19T17:29:16Z Content type: article Language: en Sources: [Benchling]() Topics: [Development](), [Framework](), [data](), [API](), [Tech Debt](), [interoperability](), [configuration](), [migration]() Tags: [api](), [benchling](), [biotechnology](), [configuration](), [data](), [development](), [framework](), [interoperability](), [migration](), [platform-engineering](), [tech-debt]() ### AI overview Benchling describes how manually integrating scientific data objects with APIs, analytics, search, configuration migration, and other platform capabilities created an MxN maintenance burden, technical debt, and behavioral drift. The article introduces a spec-first framework approach intended to make platform functionality more uniform and scalable. ### Source excerpt Reaching the limit of manual platform development Benchling's platform handles diverse scientific data, such as DNA sequences, antibodies, notebook entries, inventory containers, workflow runs, and dozens more. Each object type carries unique domain logic: how it is validated, what relationships it holds, and what actions users can perform on it. As Benchling matured, capabilities were added that customers expected to work across all these objects including REST APIs for integration, a data warehouse for analytics, search indexing, and configuration migration tools for moving setups between tenants, among many others. Each product team is expected to expose their data in all platform surface areas. However, because this process is manual it can also be brittle and costly. With M object types and N platform capabilities, and each object requires custom integration with each capability, you're maintaining MxN integration points. Add a new object? You'll need to integrate it with every platform capability. Add a new capability? You'll need to integrate it with every object. In practice, this meant product and tech debt: some objects were available via API but missing from the warehouse, or a feature was exposed in the UI but not in other platform surface areas. It also meant behavioral drift. The same object would have slightly different field names or validation logic depending on which surface you accessed it through. As Benchling grew, so did its customers. Enterprise customers expect platforms that are designed for multi-modal integration that covers the full spectrum of Benchling's data and functionality. AI is quickly reshaping how knowledge work is done across all industries. But some fundamentals have not shifted. The same integration capabilities that make enterprise architectures more powerful are what makes agents more powerful too: both require data access and interoperability. Thus a different approach was needed. Ideally one where the cost of adding types ## The Multi-Model Playbook DevFeed: [The Multi-Model Playbook]() Original publisher: [Read original article]() Author: Sumedh Bhattacharya Published: 2026-01-16T16:02:06Z Content type: tutorial Language: en Sources: [Benchling]() Topics: [Large Language Model](), [ai-coding](), [Structured-data](), [agent observability](), [pdf]() Tags: [agentic-engineering](), [ai](), [ai-agents](), [analysis](), [benchling](), [biotechnology](), [caching](), [code](), [coding](), [comparisons](), [llm](), [model](), [parallel](), [patterns]() ### AI overview Benchling describes patterns for building production AI systems across multiple model providers. The article covers modular task decomposition, prompt structure, caching, structured data presentation, provider comparisons, and applying these principles to AI coding assistants. It reports using OpenAI GPT, Anthropic Claude, Google Gemini, Meta Llama, and Amazon Nova in agent systems such as the Data Entry Agent and Compose. ### Source excerpt The Multi-Model Playbook: Patterns in Agentic Engineering Building production AI systems that work reliably across multiple model providers requires more than just swapping API keys. Over the past year, working on AI agents like the Data Entry Agent and Compose Agent at Benchling, I've learned that successful multi-provider strategies come down to understanding what's universal versus what's provider-specific, and designing around those constraints. The clearest revelation here was that the architectural principles underlying reliable software -- modularity, separation of concerns, clear interfaces -- apply just as fundamentally to AI systems as they do to traditional code. The Data Entry Agent (DEA) extracts structured data from PDFs and images, while Compose is an agent that helps scientists write electronic lab notebooks (ELNs) by extracting content from attached files, connecting that with data in Benchling's Registry, and outputting structured scientific protocols, analysis, and more. These systems currently support five different model families (OpenAI GPT, Anthropic Claude, Google Gemini, Meta Llama, and Amazon Nova), typically using four in any given run. This experience has revealed patterns that hold true across providers -- patterns around task decomposition, prompt structure, caching strategies, and data presentation. While each provider has its quirks, these foundational strategies have proven consistently effective. In this post, I'll cover: How to break down problems for optimal LLM performance Why the system versus user prompt distinction matters for caching Best practices for presenting structured data as context Practical comparisons between model providers How to apply these principles when using AI coding assistants. Breaking Down Problems: Small & Complex versus Large & Simple LLMs lose accuracy when handling multiple separate tasks simultaneously or when operating on large input contexts. The sweet spot is to give them either a small, complex task ## Scaling Scientific Data: Migrating Benchling's Schema Model for Performance at Scale DevFeed: [Scaling Scientific Data: Migrating Benchling's Schema Model for Performance at Scale]() Original publisher: [Read original article]() Author: Melody Ding Published: 2024-12-04T15:01:06Z Content type: article Language: en Sources: [Benchling]() Topics: [data](), [Structured-data](), [data-processing](), [Database](), [PostgreSQL]() Tags: [applications](), [automated](), [benchling](), [collection](), [core](), [customer](), [customers](), [data](), [data-modeling](), [database-optimization](), [model](), [performance](), [postresql](), [product](), [scalable-architecture](), [scale](), [schema](), [science](), [software-engineering](), [speed](), [storage](), [structure](), [tests]() ### AI overview Benchling describes migrating its Schema Model to a more compact structure to improve data-ingestion performance as scientific data volumes grow. The phased transition aimed to balance speed and flexibility while avoiding PostgreSQL scaling limitations, including the need for sharding. ### Source excerpt Benchling is a unified platform for scientific data. It allows scientists to collaborate on complex science, automate work, and power AI. Customers store large volumes of data on our platform, leveraging it across many applications both within Benchling and in their own infrastructure. It's critical that customer data is accessible in a performant and scalable way. In this article, we'll explore a recent shift in how we store and retrieve customer data. By migrating to a more compact structure, we've tackled key performance challenges associated with increased data volumes. This transition has required a careful balance between speed and flexibility, as well as a phased approach that minimized disruption for users. Benchling Schemas At the core of Benchling's system is Schemas, a product that allows both Benchling internal teams and customers to configure the various shapes of data, defining fields, attributes, and constraints that entities must follow. These data structures represent entities like equipment, storage, biological molecules, workflows, tasks, lab notes, and recorded results from scientific tests. Schemas reside in what we refer to as the definition layer. An example schema for defining the data structure of a molecule Each instance of a schema, referred to as a schematizable item, represents the actual data input by scientists. We call this the instance layer. These items are populated with field values conforming to the schema's defined fields. As Benchling's user base grows and the amount of schematized data ingested into the platform increases every year, optimizing the storage of field values has become crucial. Relationship between actual instances of a molecule and its defined schemaThe Challenge: Scale and Performance Historically, Benchling saw a shift from manual data upload by scientists to integrations with lab equipment, leading to automated data collection. This significantly increased the speed and volume of data ingestion. Assay results ## 10x faster python test iteration via fork(2) DevFeed: [10x faster python test iteration via fork(2)]() Original publisher: [Read original article]() Author: raylu Published: 2023-07-20T16:01:45Z Content type: tutorial Language: en Sources: [Benchling]() Topics: [Python](), [Testing](), [SQLAlchemy](), [modules](), [import](), [Code]() Tags: [benchling](), [code](), [dependencies](), [developer-productivity](), [engineering](), [fork](), [import](), [modules](), [python](), [sqlalchemy](), [testing]() ### AI overview This Benchling Engineering article explains how the Build team reduced Python test iteration time in a dependency-heavy codebase. It discusses the limitations of importlib.reload() and describes a fork-based approach that made the second test run start 10 times faster, reducing waiting by 90%. ### Source excerpt It's ideal to get feedback on your code faster -- to make a code change and see the result instantly. But, as projects get larger, reload times get longer. Each incremental dependency or bootstrap code block that adds 200ms feels worth it, but 50 of them later and it takes 10 seconds to see the result of a code change. On the Build team at Benchling, that's where we found ourselves one day. We used 146 packages which pull in 128 transitive dependencies for a total of 274 packages. We also spent a lot of time waiting for SQLAlchemy models to initialize. The result is our test harness took 10 seconds to set up. After making a code change, you'd start the test runner, wait a few seconds, alt+tab to your browser, get distracted for a few minutes, and then find out you had a typo in your code. This is a common challenge for a growing codebase, but it's something we knew we needed to fix. Here's the process we arrived at which allowed the second run of tests to start 10x faster -- 90% less waiting. While it'll work a little differently for your codebase depending on the language, dependencies, etc. you're using, hopefully this can inspire you on your journey to faster feedback and testing. importlib.reload() Since the problem is that we spend so long setting up a bunch of modules just right and then want to see the change in a single file we're editing, the most obvious solution is to use importlib.reload from the standard library. import importlib import sys import test_harness_stuff # takes 10 seconds import tests def rerun_tests(changed_path): for mod in sys.modules.values(): if mod.__file__ == changed_path: importlib.reload(mod) tests.run_tests() break if __name__ == '__main__': setup_file_watcher(rerun_tests) tests.run_tests() This (with some special handling for built-in modules, relative path resolution, and batching to handle editors that perform multiple filesystem operations per save) works alright when the file being changed is a test file (or any other leaf node ## Exposing AWS KMS Asymmetric Keys as a JWKS DevFeed: [Exposing AWS KMS Asymmetric Keys as a JWKS]() Original publisher: [Read original article]() Author: Brian Maloney Published: 2023-02-02T20:53:31Z Content type: tutorial Language: en Sources: [Benchling]() Topics: [OpenID connect (OIDC)](), [Authentication](), [Authorization](), [Security](), [Amazon Web Services](), [JSON Web Tokens](), [API](), [threat detection]() Tags: [api](), [authentication](), [authorization](), [aws](), [benchling](), [encryption](), [engineering](), [enterprise](), [identity](), [jwks](), [least-privilege](), [oauth](), [oauth-2-0](), [oauth2](), [oidc](), [openid-connect](), [private-key](), [public-key](), [secrets](), [security](), [threat-detection](), [token]() ### AI overview This Benchling article discusses service-to-service authentication with OAuth 2.0 and OpenID Connect. It explains why administrator-generated API tokens create secret-management, attribution, and least-privilege problems, and introduces private_key_jwt authentication with public-key cryptography while considering AWS KMS for private-key management and JWKS exposure. ### Source excerpt Here at Benchling, interaction with services is a large part of our business, from employees interacting with the software-as-a-service products with which we conduct our daily business, all the way down to interactions between the services that make up the Benchling application platform itself. Secure authentication and authorization to services is a long-standing issue in the industry, but one that has been improving in recent years due to the widespread adoption of modern standards such as OAuth 2.0 and OpenID Connect (OIDC). One specific use case for service-to-service authentication that is important to Benchling Security is connecting our Threat Detection Pipeline to our enterprise identity services vendor. We use this connection to connect log and other data provided by the vendor to our centralized Threat Detection Platform, where we correlate this with other sources of intelligence to detect risky or suspicious user activity in near real-time. Modern Authentication with OIDC Our specific identity services vendor offers two options for authenticating to its API: either an API token that an administrator can generate, or interaction by acting as an Application. API tokens, while very easy to use, are a poor choice for two reasons: First, they are a static secret that must be handled carefully and rotated frequently to mitigate the risk of a leaked key, which causes significant management overhead. Second, the identity services vendor links the privileges and identity of an API token inextricably to the administrator who generated it. This causes actions using the key to be attributed to the administrator and also makes it impossible to implement the principle of least privilege. Client authentication when acting as an Application allows the use of OIDC, and this vendor specifically requires the use of the private_key_jwt Client Authentication method. Enforcing this requirement is a good choice on the part of the vendor -- by using public-key encryption, no sec