Learning judgment
from people.
Helm builds behavioral environments for the teams developing AI and the businesses deciding what comes next. Our product portfolio connects company intelligence, vertical foundation models, behavioral environments, runtime judgment, Physical AI, and data custody. The larger ambition is intelligence grounded in how people, companies, and the world behave.
Autonomy needs judgment that can travel.
Helm connects expert decisions, their context, and runtime judgment during autonomous work. Behavioral environments make responses and consequences testable. Specialized models support bounded choices. Runtime integration connects the judgment to a proposed action and its operating limits.
The proof requires independent agreement with experts, useful interventions, and a manageable human review burden. Each workflow needs explicit authority, uncertainty handling, and evaluation of the final outcome.
The next environment for AI has people in it.
An agent can complete a task and still misunderstand the person. It can retrieve the right record but miss why that record matters. A product can work as designed while asking more patience, knowledge, or effort than its users have.
Helm’s central research question is how to represent the people inside these interactions well enough to make simulation useful. That requires more than a convincing profile. Goals, memory, preferences, incomplete knowledge, changing circumstances, and responses to friction all matter. The environment needs to preserve what happened, while evaluation needs to distinguish the person’s experience from the task’s technical completion.
The same foundation supports multiple product lines. AI labs need interactive environments in which agents can be evaluated and trained. Enterprises need populations and experiments that help compare customer experiences and decisions. The underlying machinery can be shared; validity, data permissions, and the claim a result supports must be established for each use.
Our starting point: a person, a shopping or service world, a goal, and an intervention. Observe the conversation, the choices, and the resulting state. Compare that evidence with what real people do.
Model what shapes a choice.
A useful simulated person has a context that persists. We want to represent goals, preferences, knowledge, time and budget constraints, relevant memories, and expectations about the interaction. Some facts are visible at the start. Others should emerge only through a relevant question or an authorized record lookup.
Our behavioral modeling direction includes choosing, asking, correcting, accepting, rejecting, waiting, returning, cooperating, and abandoning. These responses should change when the experience changes. A person who encounters repeated irrelevant recommendations should not behave as though every suggestion were equally useful.
Evidence before scale.
Grounding may come from consented interviews, licensed interaction data, reviewed customer journeys, or permitted observations. Each attribute and behavior needs an evidence basis appropriate to its use. A large synthetic population is not automatically representative, and demographic similarity does not establish behavioral similarity.
Across people and across time.
We want to study differences among people, changes within one person, and interactions among people. Longitudinal tasks test memory and adaptation. Multi-agent scenarios can test coordination, conflicting preferences, and how information moves through a group. Longer-term cognitive research examines mechanisms of memory, perception, learning, and choice, with human measurements needed to assess what those mechanisms explain.
Let actions change the situation.
Task environments include catalogs, inventory, carts, orders, payments, return flows, subscriptions, messages, and previous interactions. They should expose the interfaces an agent actually uses and preserve state as the task progresses. A changed action must be allowed to produce a different consequence.
We plan to support conversations, API and tool interactions, and browser or application surfaces. Computer-use evaluation adds questions of visual grounding, target selection, navigation, and verification after an action. The agent’s reasoning and its interface are separately inspectable parts of the experiment.
Controlled variation.
Reset the same starting world and change one factor: the model, harness, offer, interface, policy, or circumstance. Introduce missing information, inventory changes, delayed responses, interrupted sessions, or a revised preference. Repeated runs help expose variability. Environment failures need to be identified independently so they are not mislabeled as agent failures.
Keep roles separate.
The simulated person should know what that person could reasonably know. The agent should discover relevant context through the allowed interaction. The evaluator may inspect privileged state, but its rubric and hidden answers should not leak into either participant’s behavior.
Useful feedback has more than one dimension.
| Layer | Question | Evidence |
|---|---|---|
| Person | Does the simulator respond like the intended people? | Held-out human behavior and changes under intervention |
| Model | Is the bounded judgment appropriate? | Preference discovery, choices, uncertainty, visual grounding |
| Harness | Does execution preserve context and recover? | Memory, tools, permissions, timing, retries |
| Agent | Did the person’s actual goal get met? | Final state, preference fit, effort, unintended effects |
| Experience | What changes for different people under each alternative? | Behavioral trajectories, cohort differences, validation against real users |
Evaluation combines deterministic state checks with expert-reviewed rubrics and human evaluation. A successful transaction, satisfaction, and a business outcome are distinct measures. Optimizing one should not silently override the others.
For frontier and neo labs.
Lab products include a versioned user simulator and environment, executable tasks, evaluation criteria, traces, and a report of known validity limits. Evaluation and training are separate products and permissions. Training trajectories and reward interfaces should be supplied only where their rights and quality support that use.
Evaluation splits should separate people, scenarios, and time where the research question requires it. Training gains must be tested on independent interactions and human evidence. Improvement against the same simulator used for training is useful debugging information, but does not establish real-world transfer.
For enterprise teams.
A comparative study should answer a concrete question about a customer-facing agent, product flow, offer, or policy. The output includes where the alternatives differ, whose needs are missed, what assumptions matter, and which findings deserve a real-user check. Statistical population claims require a suitable sampling and validation design.
Make realism an empirical question.
Simulator evaluation operates at several levels. First, does it preserve the person’s context and knowledge boundaries? Second, does it react plausibly to the interaction? Third, do its responses correspond to observed human behavior in the intended population and task? These are different standards.
- Hold out people and situations. Preserve independent human evidence that was not used to shape the simulator.
- Compare responses to interventions. Test whether helpful and degraded experiences change behavior in the same direction as they do for real participants.
- Measure distributions and failure types. Inspect clarification, correction, acceptance, abandonment, and preference satisfaction, with uncertainty and subgroup sample sizes visible.
- Use strong baselines. Compare against a generic user simulator, simple rules, and the customer’s existing evaluation process.
- Track where validity ends. A result for a given task, cohort, language, and context does not automatically transfer to another.
These are research and product design requirements. We are not presenting measured Helm accuracy, calibration, or transfer results on this site. The first engagements should define what evidence would support a useful conclusion and what would make us reject it.
From a customer interaction to a company decision.
The longer-term opportunity is a company-specific account of people, products, policies, choices, and outcomes. A private population can become a reusable setting for comparing changes. Connecting studies to actual observations can reveal which assumptions hold and where the model needs revision.
Our company decision models combine that behavioral understanding with organizational goals, constraints, operating history, and expert judgment. The output is a bounded choice with its supporting evidence and uncertainty.
Decision-model training and serving.
A typed decision interface could accept a state, question, and candidate options, then return a selection and calibrated scores. We are interested in supervised adaptation and lightweight adapters for text, images, documents, screens, and video. Training, calibration, and evaluation data must remain separate, with model and data versions linked. Local and API serving should preserve the same decision contract.
Routing and intelligent action.
Model and harness comparisons can inform which execution path fits a task. Future routing could weigh demonstrated outcome quality, personal fit, permissions, latency, and cost. A broader agent would retain planning, recovery, and final-state verification; a specialized decision model would handle defined judgments within that process.
Each extension has a proof requirement. Detecting a bad customer interaction does not establish that a model can predict revenue. Choosing a next action does not establish a valid causal effect. Company intelligence should grow from measured usefulness in bounded decisions.
A shared engine does not require shared private data.
We are designing a data architecture that links source observations, population versions, model adaptations, environments, runs, and outcomes. Cryptographic signatures and immutable version references can establish origin and integrity. Whether an observation or prediction is accurate requires separate evidence.
Ownership, consent, access, permitted transformations, retention, and model-training rights need to be explicit. Customer-specific populations, policies, traces, and adaptations should remain within the agreed scope. An enterprise study does not imply permission to train another customer’s model.
Reusable software, independently created worlds, and separately licensed research can support both product lines. The target deployment architecture includes customer-controlled execution and clear boundaries for any hosted processing. Specific controls and integrations are part of engagement scoping; this site does not claim certifications or deployments that have not been established.
A shared substrate for brain dynamics.
Helm Brain Model is our research framework for representing brain state and deriving task-specific models at different regions, resolutions, and timescales. Its dedicated page explains the architecture, reported experiments, limitations, and research artifacts.
People, companies, and the physical world.
Causal worlds and cross-domain foresight.
Our research horizon includes modeling state, action, mechanisms, and downstream outcomes across company systems. Economic changes, supply-chain interruptions, customer responses, and operating choices can interact. Controlled interventions and observed outcomes are necessary to distinguish an association from evidence about what a decision changes.
Real-to-simulation environments.
Scans, images, video, and CAD could become editable worlds with objects, geometry, materials, and physical constraints. Measured and inferred properties should retain distinct provenance. Visual realism alone is insufficient for contact, motion, or interaction studies.
Human–robot interaction and humanoid evaluation.
The behavioral foundation may eventually support environments where people and embodied agents share space and work. Relevant questions include communication, intent interpretation, coordination, task completion, recovery, and physical limits. Humanoid and manipulation evaluation require robot-specific infrastructure and comparison with hardware observations.
Inference for embodied action.
Our longer-term scope includes policy serving, observation and action interfaces, simulation and hardware adapters, and the full observation-to-action delay. Cloud inference, local control, and fallback behavior must be evaluated against the physical task. Success in software simulation does not validate a robot deployment.
These remain research horizons. Expansion should follow a concrete partner need, appropriate technical capability, and evidence specific to the new domain.
Start with one world and one decision.
Helm engagements span company intelligence, domain models, behavioral environments, runtime judgment, Physical AI, and data. Teams select the products and integrations that serve their operation or research objective, with a named owner and agreed evaluation criteria.
A lab environment pack should be runnable inside the buyer’s evaluation stack and documented well enough to inspect. An enterprise study should end with an interpretable decision report and reusable scenarios. Product access, integrations, human research, and hardware evaluation follow the engagement’s agreed requirements and schedule.
Commercial success should mean recurring usefulness: a lab returns for new environments or licensed training material; an enterprise reuses its private population when the experience changes. Price and scope should reflect the environment, human validation work, permitted use, and compute required.
Three people. Six illustrative paths.
The behavioral simulation page includes a shopper with an unstated deadline, a customer who cannot use a printable return label, and a subscriber whose prior preferences affect a plan change. Two agent behaviors produce different scripted interactions and final outcomes.
All people, prices, statements, and results are fictional. JavaScript selects predefined examples locally. The preview does not run a language model or behavioral simulator, estimate population response, connect customer systems, produce training data, or sign records. The animated point cloud is a visual metaphor, not a measured population.