Atinary uses AI to choose the next useful experiment in a laboratory

Atinary’s SDLabs helps researchers choose experiments and learn from the results. It can support manual laboratory work or connect to automation, making the main decision less about buying a robot and more about defining a measurable objective. The system is useful when the next experiment is expensive enough that choosing it more carefully can materially improve a research programme.

01 / ProductSDLabs turns experimental design into an iterative software workflow

The SDLabs product page describes a code-free platform with AI optimisers and visualisation tools. Researchers define a problem, run recommended experiments and feed measurements back into the system. The public offer supports manual experimentation as well as connections to laboratory equipment and software. Robotic execution is therefore an integration choice, not a prerequisite for every use.

Atinary’s technology overview names Atinary Falcon, constraint-aware Emmental and transfer-learning-oriented SeMOpt. These are different capabilities within the optimisation approach. The buyer should ask which method is appropriate for its variables, constraints and available data. A product catalogue of algorithms does not establish that every method is equally suited to every experimental problem.

The platform is relevant to research such as chemistry and materials development, where several controllable variables influence a measured outcome. It is not a general scientific oracle. A useful objective might balance yield with a constraint on a reagent or operating condition. A poorly specified objective can produce an excellent numerical answer that the laboratory cannot or should not use.

02 / AudienceThe strongest audience has a costly experiment and a reliable measurement

A process chemistry team optimising a reaction is a plausible customer. It can define the factors it is willing to vary, identify infeasible combinations and measure an outcome consistently. The value of the system depends on what the team learns per unit of experimental effort. A successful deployment should help it make a better decision, not simply make the experiment count look smaller.

A materials team exploring formulations can have a similar need, but the constraints may differ. Some ingredients cannot be combined, some measurements take longer and some objectives compete. The team should be able to express those conditions clearly. If the variables or measurement process are still poorly understood, a preliminary scientific investigation may be more valuable than immediate optimisation.

The Lila Sciences blueprint provides context on AI-driven experimental science and automated laboratories. The Benchling blueprint helps distinguish experiment optimisation from the broader management of research records. SDLabs can sit within a laboratory workflow, but it should not be assumed to replace every system that stores samples, protocols and organisational knowledge.

03 / WorkflowProposed workflow: begin manually, then automate a process that already makes sense

Choose a bounded experimental problem with a decision deadline. This is a proposed evaluation workflow, not a Sequenced laboratory benchmark. Define the objective, allowed variables, measurement method and constraints. Include practical limitations such as available stock, safe operating ranges and combinations the laboratory cannot execute. The first deliverable should be a problem specification that a scientist can review independently of the software.

Run a small initial set that establishes measurement reliability and provides a baseline. Record failed or invalid experiments separately from valid low-performing results. These are different observations: an experiment that did not execute cannot automatically be treated as proof that the proposed conditions were scientifically poor. Agree how such cases are represented before they enter the learning loop.

Use SDLabs to propose a next batch, then have the responsible scientist review feasibility. After execution, return the measurements with enough context to interpret them. Inspect whether recommendations are exploring uncertainty or refining a promising region. Both can be useful. The team should understand how the next batch relates to the current decision rather than approve conditions simply because an algorithm produced them.

Atinary’s self-driving laboratory description connects design, making, testing, analysis and learning. If manual work establishes a useful loop, consider instrument or laboratory software integration through the documented API and SDK routes. Validate sample identity, units, timestamps and failure reporting before increasing automation. A fast loop with mismatched measurements can confidently optimise the wrong experiment.

Keep the scientist responsible for interpreting the result and deciding when the programme has enough evidence. Verify the selected conditions independently and under the operating conditions that matter for the next stage. The best laboratory-scale result may not transfer unchanged to another scale or instrument. Treat that transition as a new scientific question, not a clerical deployment step.

04 / PricingThe AWS listing provides a specific pilot reference, with important conditions

The AWS Marketplace listing is titled “Atinary SDLabs [Private Offer Only]”. As consulted on 29 October 2026, its pricing table lists an SDLabs pilot at $25,000 per month for up to 20 users, with a two-month pilot recommended. The purchase unit represents a month, not an experiment or an additional user. The page offers a custom quotation route.

The one-month listed contract price is a useful budgeting reference, but it is not proof that a buyer can obtain any scope on those terms without a private offer. Two months at the displayed monthly rate would arithmetically be $50,000 before any separately applicable costs or negotiated changes. That is an illustration, not a quotation. The listing also warns that additional AWS infrastructure costs may apply.

Ask the private offer to state the actual duration, users, support, onboarding and integration scope. Confirm how additional users are treated and which AWS costs, if any, the customer bears. Refund arrangements are described as governed by the direct agreement. No purchase, private offer request or refund commitment was made during this research.

05 / DistinctionsIts useful distinction is separating experiment choice from robotic ownership

Atinary is notable for a concrete optimisation product that can support existing laboratories before a full automation project. That makes an incremental evaluation possible: first determine whether the recommendations improve experimental decisions, then decide whether robotic or software integration is justified. The value of the optimiser and the value of automation can be measured separately.

The Takeda case study describes applying the approach to reaction optimisation. It gives a specific pharmaceutical research context, but it remains a vendor-published case. The reviewed pages use differing iteration descriptions around the example, so this article does not turn them into a single numerical performance promise. A prospective buyer should request the experimental protocol and a comparison relevant to its own problem.

Constraints and multiple objectives are especially important in real laboratories. A numerically high-yielding condition may be undesirable if it consumes an unavailable material or requires an impractical process. The useful evaluation asks whether SDLabs can represent the actual feasible space and expose trade-offs in a form the scientific team can act on.

06 / QuestionsData, integration and the meaning of a good result need careful definition

Which variables, constraints and objective types are supported for the intended workflow? How does the system represent noisy measurements, missing outcomes or delayed results? What information is needed before transfer learning is appropriate? These questions are more useful than assuming that a large collection of optimisers guarantees strong performance on a new problem.

The SDLabs page states that client intellectual property remains with the client and describes cloud hosting and security practices. Treat those as vendor statements to confirm in the actual agreement. Determine how experimental data is stored, exported and deleted, and who can access the project. The research here did not inspect a private security assessment or negotiated data-processing terms.

For automation, establish who owns the integration and maintains it as instruments or laboratory systems change. Ask how the loop behaves when a measurement is invalid, a sample is lost or an instrument is unavailable. Also distinguish Atinary’s descriptions of its own self-driving laboratory development from a generally available, bookable laboratory service; the reviewed pages do not establish that entitlement.

07 / DecisionBuy a decision loop with measurable scientific value

Atinary is a useful candidate when a team can define a repeatable experimental objective and wants software to guide the next batch. Begin with a bounded pilot and a baseline that reflects how the team currently works. Measure decision quality, experimental effort and staff time, including the effort required to prepare data and investigate failures.

Proceed when the pilot’s scientific question, commercial scope and data arrangements are explicit. Automation can follow once the underlying process is reliable. If the measurement is unstable or the objective does not reflect the desired outcome, improve those foundations first. A better optimiser cannot compensate for repeatedly asking the laboratory the wrong question.