Architecture

System overview

Bionamic connects researchers, shared data, AI models and scientific tools. Researchers use the application in a web browser. The browser connects to an application server, which manages the workspace and coordinates sign-in with an authentication server, requests to AI models, and tool execution.

The browser provides the user interface: researchers open files, edit workbooks, view molecules and communicate with assistants and channel agents. It sends requests to the application server over an encrypted HTTPS connection.

The application server manages shared files, accounts, permissions, conversations and agent runtimes. It checks whether each request is permitted and coordinates the services needed to carry it out.

The authentication server verifies who the researcher is. During sign-in, the browser is redirected to this server and then returns to the application. The application server verifies the sign-in result with the authentication server and checks whether the researcher has access to the instance. The application server remains responsible for permissions within the workspace.

Model inference is a separate part of the architecture. The agent runtime sends conversation context through Bionamic’s model gateway to a configured inference server. The gateway controls permitted endpoints, routes requests, and records usage and costs against the instance’s budget. The model returns text or requests to use tools.

Tools perform actions and computations requested by researchers and agents. The application coordinates workspace access, agent-written scripts in sandboxes, and scientific jobs on the compute service. Results can be saved in the workspace or included in the conversation. The toolsmith has separate model access through the compute service, as explained below.

The following sections explain these components, the data they handle, and the controls on their access and execution.

Shared workspace and agents

The Bionamic system provides a shared file system for a team of biotech researchers. Researchers can read and write files, organize them into folders, and work with them through applications in the browser. The files can include workbooks, sequences, next-generation sequencing (NGS) data, protein structures in PDB format, notes, and any other type of file.

Bionamic includes applications for working with several of these file types. The workbook presents scientific data in a spreadsheet, while the molecule viewer displays sequences and three-dimensional structures. The Files app lets researchers browse and organize the shared files. Other file types can be stored in the same file system even when Bionamic does not have a dedicated viewer for them.

Bionamic can be configured to include AI agents. It is possible to use Bionamic without AI agents. However, including AI agents generally results in a more capable system. There are two types of AI agents: personal assistants and channel agents.

A personal assistant is a private agent for an individual researcher. It appears alongside the applications, and its conversation is private to the researcher’s account. Background model calls summarize conversation content into a private index that helps the assistant find earlier work; these calls do not require a separate user request.

When the researcher sends a request, the assistant receives context identifying the application and file they have open. For a workbook, this includes the sheet and selection, together with a reference to the saved revision. This helps the assistant understand what the researcher is referring to and read the relevant material through its tools. The entire workspace is not automatically included in every model request.

A channel is a shared conversation in which researchers and channel agents can write posts and follow up together. When automatic listening is enabled, new posts and recent context are sent to the configured model so the agent can decide whether to respond, including when it is not mentioned.

Both types of agent have the same basic capabilities. They can explain data, read and modify files, edit workbooks, run scripts, and use scientific tools such as structure prediction. Their access depends on the resources and permissions configured for them. Results saved in shared files can be opened and used by the team, including when the work was requested in a private assistant conversation.

Both types of AI agents use AI models (neural networks) and tools. Bionamic manages the model calls, tool execution, and access to shared data. The following sections explain how these parts work together and how their access and execution are controlled.

The AI agent

Bionamic operates its own agent runtime (harness). The runtime connects to the AI model inference provider, sends a request, and receives a response. The response can contain text for the conversation or requests to use tools. When the model requests a tool, the runtime executes the tool call and sends the result back to the model. This cycle continues until the agent finishes its response or reaches a configured limit.

The runtime supports conversations, reading and writing files, editing a workbook, writing and running a script, and submitting scientific computations. The model decides which tools to request based on the task and the results it receives. The runtime manages the execution of those requests through Bionamic’s tool and service interfaces.

The runtime runs outside the environment where scripts and code written by the AI model are stored and executed. Provider credentials and API keys are kept outside that environment, so the model’s code cannot read them directly. Access to administrative information, such as account records and user lists, is controlled through the application’s authorized interfaces.

Executions have bounded resources and lifecycle controls. Failures from a tool or service can be returned to the agent as results to handle. A failed run does not necessarily undo work that was already saved, so the recorded actions and resulting files are important when reviewing what happened.

Inference providers and local models

The implementation supports hosted inference and local models. With hosted inference, Bionamic sends model requests to an external inference service. With local inference, the requests are processed by a model server running on Bionamic-operated or customer-selected infrastructure.

The tables show examples from Bionamic’s current model registry. The models enabled for each customer depend on the instance configuration.

The list can be extended as additional models and inference services become available and are integrated and tested. Customers participate in configuring their instance. Together we choose the permitted models, inference providers, processing regions, and usage limits based on the customer’s requirements for capability, cost, and data handling. The configuration can be changed without moving the shared files and conversations to another application.

The model gateway checks requests against the endpoints permitted for the instance and applies its configured usage controls. A model cannot select an arbitrary inference provider for itself. Bionamic authenticates requests to Amazon Bedrock using AWS API access keys. These keys and other inference service credentials are held outside the environment executing the agent’s scripts and code.

The location of the inference service is separate from the location of the workspace and scientific compute services. For example, a workspace hosted by Bionamic can use a local model, while a customer-hosted workspace can use an external inference provider. Some Bedrock endpoints use regional routing and others use global routing; the processing location must be considered when selecting an endpoint.

Model escalation and efficient use of inference

A customer environment can be configured with a smaller model and a stronger model. Runs begin with the smaller model, which can complete suitable tasks or request a handover when it needs additional capability. The decision is made during the work, with the information already gathered, rather than by asking the user to select a model for each question.

On escalation, the stronger model receives the visible conversation, tool calls, and their results, together with the handover reason. It continues from that work. Provider-specific hidden reasoning is not transferred as though it were ordinary conversation history. If the configured models are the same, there is no separate escalation step.

The purpose is to avoid spending expensive model capacity on every part of every request. Straightforward work can finish on the smaller model, while harder work uses the stronger one. This can reduce inference cost and the amount of work performed by the expensive model; it is not a guarantee that the total number of tokens is lower on each run. A handover itself has a context-processing cost.

Bionamic limits monthly inference spending through a configurable budget for each customer instance, shared by its agents. The model gateway tracks usage and provides warnings as the budget is approached. With a hard stop enabled, it refuses new inference requests once recorded spending reaches the monthly limit. Requests already in progress can still incur costs, so this is not an exact cap on the provider’s bill.

Model selection, escalation behavior, usage records, and configured budgets provide operational controls. Cost efficiency does not establish answer quality. The results of an analysis still need to be judged from the methods, inputs, and evidence.

The gate

The gate is the service boundary through which controlled workspace operations are performed. It associates requests with authenticated users or execution identities, validates the operation and its arguments, and applies the relevant ownership and access rules. An agent cannot grant itself a different identity simply by putting one in a tool argument.

The gate records permitted and refused operations handled by its interfaces in an append-only, hash-chained access log, including the caller, requested action, target and decision. It also coordinates job submissions and tool installation requests, validating completion reports before updating workspace state. Direct reads and writes within a live database are not individually recorded as gate operations.

These checks enforce identity, structure, ownership, and state transitions. They do not establish that a model’s scientific interpretation is correct. The distinction matters when reviewing an AI system: software authorization and scientific validation solve different problems.

Scientific tools and compute jobs

Scientific tools execute defined computations, such as sequence annotation or structure prediction, and return outputs that can be examined independently of the agent’s explanation. OAS and SAbDab search tools query local database snapshots on Bionamic’s servers rather than sending search sequences to those database providers. This describes the search itself; an agent’s model requests may still include the sequence or results.

Computations are submitted with defined inputs and a selected tool implementation. The compute service manages execution, including scheduling and resource availability, and reports status and outputs through its interface. Job records associate the computation with its originating request and retain references to the inputs and resulting artifacts.

A computation can take longer than a conversational response. Keeping the job state outside a model call allows Bionamic to follow it and resume the associated work when the result becomes available. Failures and cancellations remain distinct from successful completion; a model’s statement that a tool ran is not a substitute for the job record.

The toolsmith and custom tools

When a task needs a capability that is not already available, an agent can submit a tool request. The toolsmith builds a reusable tool from a description of the capability, its input and output contract, and its software requirements. It runs as an installation workflow on the compute service, separately from the agent working on customer files.

The toolsmith is not given the customer workspace. Requests are screened before entering this workflow, and development and checks use synthetic or public fixtures rather than customer research files. The installation service has its own model access. That separation is important both for data disclosure and for understanding which inference provider is involved in creating a tool.

A candidate tool is built and checked against its declared interface. The installation process produces a versioned candidate and verification records. The gate checks the candidate’s ownership, revision, contract, environment identity, and verification evidence before registration and activation under the environment’s policy. The toolsmith cannot authorize its own candidate by declaring it safe.

Once activated, the tool runs through the compute-job interface with the relevant execution limits. Replacement and withdrawal are managed through the registration lifecycle, so a new candidate and an available tool are not the same state. Installation and activation can be automatic under the configured policy; automatic does not mean that the gate’s checks are bypassed.

These checks provide evidence that the packaged tool meets technical requirements and executes its test cases. They are not a certification of scientific validity, a comprehensive software security audit, or proof that the tool is appropriate for every dataset. Customers should review newly introduced methods according to the importance of the decisions they support.

Sandboxes and network boundaries

Agent-written code runs inside Linux sandboxes using namespaces, restricted filesystem mounts, dropped privileges and resource limits. System-call filtering restricts process inspection, and runs cannot acquire additional privileges. The runtime supplies the files and service interfaces needed for the task; provider credentials remain outside the sandbox.

Interactive agent execution and scientific compute jobs have separate environments. GPU work is submitted as a computation rather than giving the conversational agent direct access to the host’s GPU devices. Job execution is constrained by its declared inputs, outputs, and available resources.

Agents can access public internet resources. The network boundary blocks access to protected host, private and cloud-metadata networks. A host-side logger records outbound connections and refused attempts; a logger outage does not stop traffic. Toolsmith installations download packages through the compute service’s egress proxy. External services also provide hosted inference and email delivery; permitted connections are reviewed for each customer environment.

Sandboxing limits what code can reach and do. It does not remove the need to treat external documents and tool results as untrusted input, or prevent an incorrect conclusion from appearing in an otherwise valid response. Isolation, authorization, and human review are complementary controls.

Identity and access

Bionamic supports sign-in with passkeys or emailed sign-in links and does not store user passwords. Team administration controls membership and application access. Single Sign-On and IP restrictions are available on request.

User requests and agent runs have identities within the system. The gate applies ownership and access checks when controlled workspace operations are requested. An agent operates through the resources and interfaces made available to its run; it does not obtain unrestricted administrator access because a user asks it to perform an action.

Customer isolation and data protection

Each customer has a separate application environment. Customers may share physical hardware. A dedicated machine is available on request.

Browser communication uses encrypted transport. Encryption at rest is an optional deployment requirement and should be confirmed for the environment concerned. The protection of stored data includes the relevant storage, key management, and backup arrangements.

Versioned workspace files use controlled publication and revision checks to preserve history and identify conflicting changes. Live files, including SQLite databases and FASTQ files, do not have that revision history or content-hash protection. Databases can be edited in place using SQLite’s locking; recovery arrangements for live files must be established separately.

Bionamic’s own retention is separate from inference-provider retention. The workspace stores files and revisions, conversations, and execution records so that work can be continued and reviewed. The inference gateway’s usage ledger records metadata and costs rather than prompt content; conversation and execution records can contain research content. A provider’s zero-retention policy therefore does not mean that Bionamic deletes the conversation or its results.

Researchers see shared data according to their application access, while personal assistant conversations are associated with individual accounts. Infrastructure operators may have administrative access to stored data and operational records. Who operates the environment, who can access those records, and the retention and deletion arrangements for live data, logs, and backups must be established for the deployment. We discuss these requirements with customers rather than assuming one policy fits every instance.

Data access and retention for local models

Local models run on Bionamic servers or on customers’ own servers. Bionamic’s current local inference endpoint has a configured retention policy of zero days, and requests are not sent to an external inference provider. Access to the local servers is managed in the same way as access to other application data. This inference-retention policy is separate from Bionamic’s storage of conversations and workspace results.

Other local models can also be configured. Customers participate in selecting the models for their instance, and each local deployment is reviewed for compatibility, data access, retention and training-use policies before it is enabled.

Data access and retention for hosted models

A model request can contain the researcher’s messages, relevant conversation history, file contents read by the agent, and results returned by tools. The inference service processes the information included in that request. Access to a shared file does not mean the entire file system is sent to the model on every turn, but content retrieved during a task may become part of a subsequent request.

Amazon Bedrock runs AI models through AWS’s inference service. According to AWS, model developers cannot access customer prompts or responses through Bedrock, and neither AWS nor the model developers use this data to train their models. These commitments apply to models accessed through Bedrock. See AWS’s explanation of model data use .

Training use, retention, and human access are separate questions. A service can exclude data from model training while retaining it for other purposes. Bedrock retention depends on the selected model, API behavior, and account or project settings; some models require retention and may permit AWS review for abuse prevention. We review the applicable settings and terms with the customer when configuring an instance, including any requirement for zero data retention. See AWS’s data-retention documentation .

Bionamic can also be configured to use other hosted inference providers. Customers participate in selecting the services for their instance. Each provider is reviewed for compatibility, data access, retention and training-use policies before it is enabled.

Deployment and data location

Bionamic-operated application servers are hosted on UpCloud. Bionamic can also be deployed with a customer’s preferred cloud provider or installed on customer Linux infrastructure. The chosen arrangement determines which party operates the application, storage, compute resources, and supporting services.

For a deployment review, establish the locations of workspace storage, backups, inference endpoints, and scientific compute services separately. Also identify external connections required by the intended workflows. A single location label for the application is not enough to describe all of these flows.

Backup schedules, retention, restoration procedures, update responsibilities, and incident contacts should be confirmed for the proposed deployment. We discuss these operational arrangements with customers rather than presenting one configuration as universal.

Traceability and customer review

The system retains conversation messages, execution records, gate access logs, model handovers, file revisions where supported, computation inputs and outputs, and tool registration records. Execution records document an agent run’s actions and outcomes; gate access logs document authorization decisions. Together they help establish what was requested, what ran, and which artifacts were produced.

Not all operational records are presented in the end-user interface, and retention and access should be established as part of a customer review. We can discuss the deployed components, model endpoints, compute locations, access policies, and available operational evidence for a particular environment.

The records available to an administrator or to Bionamic’s operators are not necessarily the same as those shown to a workspace member. During a security review, we can clarify which records exist, who can access them, and the applicable retention and investigation procedures.

Customer security and privacy review

We welcome technical questions about a proposed or existing deployment. A useful review covers identity and access, customer isolation, data locations, provider terms, network connections, tool installation policy, operational records, and responsibilities for maintaining the environment.

For personal-data processing, the relevant roles, contractual terms, retention requirements, and deployment settings should be reviewed for the intended use. The website privacy policy describes this public website; customer application arrangements require their own review.

Contact info@bionamic.io to discuss architecture, deployment, or security requirements.