Frontier R&D
Updated
3
Active research streams: agent architectures, post-quantum, consensus
Open
Peer-reviewed publications and selected open-source releases
12-18 mos
Typical horizon from research output to production capability
What does ColdAI do for Frontier R&D?
ColdAI's Frontier R&D practice answers technical questions that papers, standards and vendor roadmaps leave open, in agent architectures, post-quantum cryptography, consensus mechanisms, neural architecture search, computational biology and quantum computing. Each engagement turns a written question into falsifiable hypotheses, agrees how results will be judged before anything runs and fixes ownership and publication terms first, so a negative answer is as usable as a positive one.
“Research that never ships is academic vanity. Every active research stream at ColdAI has a named productisation owner inside the company before the first paper is written.”
What capabilities does ColdAI bring to Frontier R&D?
In depth
Research method, worked through
How we write a brief, settle IP and publication terms, and design evaluations for three of the example questions above.
- 01GuideWriting an R&D brief: hypotheses and stopping rulesHow to write an R&D research brief: tie the question to a decision, check prior work, write falsifiable hypotheses and agree stopping rules before experiments.
- 02ComparisonCommissioned research: IP ownership and publication optionsCompare four ways to arrange IP and publication in commissioned research, from client-owned and confidential to open source, and why patent filing comes first.
- 03ProcessDiagnosing agent memory failures: a test protocolA controlled protocol for agent memory evaluation: build a long-horizon task suite, replay tool calls, ablate one component at a time and classify each failure.
- 04ChecklistBenchmarking BFT consensus under your own workloadA checklist for BFT consensus benchmarking: model your own traffic, emulate real latency, inject faults, measure finality tails and tune every candidate fairly.
- 05Deep divePost-quantum signatures in ledgers: what to measureWhat NIST post-quantum signatures cost a ledger in transaction size, bandwidth, state growth and verification, and how to measure it on your own network.
Questions that justify research
Research is the right tool when the answer is not in the literature or a vendor roadmap, and the decision it informs is worth testing properly. A payments team must decide whether its ledger signatures need a post-quantum migration plan now, and wants evidence rather than opinion. An agent system performs well in trials but loses context across sessions, and nobody can say whether the fault lies in the memory design or the model. A consortium choosing a Byzantine fault-tolerant consensus design needs throughput and finality measured under its own load profile. Sponsors are usually a CTO, chief scientist or innovation lead who would rather wait for a careful answer than act on a guess.
How a research engagement is framed
Success criteria and publication terms are fixed before the first experiment
Question and prior work
Output: a one-page question statement and a review of published work, standards and open-source implementations. Decision: whether the question genuinely needs research, or can be answered from what already exists.
Hypotheses and evaluation plan
Output: testable hypotheses, metrics, baselines, datasets or test harnesses, and the result that would count as negative. Decision: sign off the success and stopping criteria before any experiment runs.
Experiments
Reproducible experiments with code, configuration and data under version control, reported at agreed checkpoints. Output: interim readouts. Decision: at each checkpoint, continue, narrow the question or stop.
Findings
Output: a technical report stating what was tested, what held, what did not, and the limits on confidence. Decision: whether the results justify a prototype, further research or no action.
Publication and transfer
Output: a transfer package for engineers and, where the agreed terms allow, a paper or open-source release. Decision: publish, protect or keep confidential, and who builds next.
Research outputs
| Deliverable | What it contains | Who uses it |
|---|---|---|
| Research brief | The question, scope boundaries, hypotheses, evaluation metrics, baselines and stopping criteria | Research sponsor and steering group |
| Prior-art review | Relevant papers, standards and open-source implementations, with notes on how far each applies to your case | Your technical leads and IP counsel |
| Experimental codebase | Versioned code, configurations, data-provenance notes and scripts that reproduce every reported result | Your engineers and any external reviewer |
| Evaluation results | Measurements against the agreed baselines, statistical treatment, negative results and known limitations | Architects deciding whether to adopt |
| Technical report | Method, findings, threats to validity and recommended next steps, with a summary written for non-specialists | Executives and investment committees |
| Transfer package | Reference implementation notes, integration constraints and the open questions an engineering team will meet | Product and platform teams |
Areas of research interest
Each is an area where we take on scoped questions, not a claim of settled results
Multi-agent systems
How agents divide work, reach agreement and keep memory across sessions, studied on defined tasks with completion rates and failure modes recorded.
Post-quantum cryptography
Lattice-based encryption, hash-based signatures and quantum-resistant key exchange, examined for migration cost and performance inside existing distributed systems.
Consensus mechanisms
Byzantine fault-tolerant protocols compared on throughput, finality and energy use under network conditions that match the client's deployment.
Neural architecture search
Automated search over model designs for a specific task, judged against a hand-designed baseline on accuracy and compute cost.
Computational biology
Machine-learning methods for protein structure, drug interaction and genomic analysis, applied to questions framed with the client's domain scientists.
Quantum computing
Quantum algorithm design, error correction and hybrid quantum-classical methods, assessed against the best classical approach for the same problem.
Who should run your research
| Internal team | Large consultancy | ColdAI | |
|---|---|---|---|
| Framing the question | Knows the business problem best | Strong at framing for executives; less often runs the experiments | We write the question and hypotheses with you, then test them ourselves |
| Specialist depth | Rare outside organisations with their own research lab | Varies; research is often subcontracted to universities | Concentrated in AI, cryptography, distributed systems and quantum computing |
| Open-ended, multi-year science | A corporate lab suits a long agenda | Rarely offered | Not our model; a university partnership is usually the better route |
| Confidentiality and IP control | Complete | Negotiated; commonly client-owned | Agreed per engagement in writing, before work starts |
| Route to production | Depends on links between research and engineering | Hand-off to implementation teams, often separate | Research and engineering sit in one firm, so findings can pass to our development practice |
| Publication | Set by your own policies | Mostly thought leadership rather than peer-reviewed work | Selected outputs appear at /publications/research/ where the terms allow |
When research with us is the wrong choice
- The answer already exists
- You need a guaranteed result by a fixed date
- The agenda is open-ended basic science
- You need certification or regulatory evidence
Before you commission research
Put the research question in writing
Send us the question you cannot yet answer and the decision that depends on it. We will tell you whether it needs research at all, what a first brief would test, and how ownership and publication could be arranged.
Propose a research questionResearch, a prototype or a literature review: classifying the question
Many questions brought to a research team are better answered another way. Sorting them first saves more money than any later step.
- If
Published work, a standard or a maintained open-source project already answers the question for conditions like yours.
ThenCommission a short prior-art review, then move to implementation through consulting or development.
Rediscovering a known answer through experiments costs more and teaches nothing new.
- If
The method is known to work, but nobody knows whether it fits your systems, data or constraints.
ThenRun an engineering spike or prototype with clear acceptance criteria.
Fit questions resolve fastest by building, and a failed prototype is itself diagnostic.
- If
Nobody can say with evidence whether an approach works under your conditions, and the decision justifies a careful answer.
ThenCommission research: a brief with hypotheses, a baseline, an evaluation plan and stopping rules.
Only a controlled study separates a real effect from noise, vendor optimism or a weak comparison.
- If
The question is open-ended science with no decision attached and a horizon of years.
ThenFund a university collaboration or an internal lab programme instead.
Commissioned research works best on bounded questions tied to a decision.
How evaluation is designed in each research area
The method is shared across areas, but the baseline to beat and the easiest way to fool yourself differ. This is where an evaluation plan starts.
| Area | Baseline it must beat | What gets measured | Most common threat to validity |
|---|---|---|---|
| Agent architectures | The current agent design, or a single well-prompted agent | Task completion and correct recall on long-horizon suites with known answers, over repeated runs | Run-to-run variance read as an effect; test tasks unlike production |
| Post-quantum cryptography | The classical scheme in use today | Key and signature sizes, bandwidth, storage growth and verification throughput in your system | Immature implementations and test hardware unlike production |
| Consensus mechanisms | The protocol currently proposed | Sustained throughput at a finality bound, finality tails and behaviour under faults | Unequal tuning, idealised networks and fault-free runs |
| Neural architecture search | A strong hand-designed model trained on the same budget | Held-out accuracy against inference compute on the target hardware, plus the cost of the search | Leaving out search cost, or an under-trained baseline |
| Computational biology | An established physics-based or statistical method chosen with your scientists | Agreement with experimental measurements on targets held out from training | Leakage between training and test sets through similar sequences or structures |
| Quantum computing | The strongest classical algorithm and solver for the same instance | Solution quality and time-to-solution, including classical pre- and post-processing | Weak classical baselines and instances too small to say anything about scale |
Three of these designs are worked through in full on the pages below: agent memory, consensus benchmarking and post-quantum signatures.
Hypothetical example: architecture search for an edge device
What makes a research result reproducible enough to act on
A result your engineers cannot rerun is an anecdote. Our experimental codebases are delivered with versioned code, configurations, provenance notes and scripts that reproduce every reported result1. The checklist below is a fair test for any research you commission, ours included.
Ways commissioned research loses its value
The question drifts during the work
Early signalCheckpoint readouts cover topics that are not in the brief.
MitigationHold every readout against the signed brief and record any change of question as a formal decision.
The baseline is weak
Early signalThe new approach wins easily against an old or untuned comparison.
MitigationAgree the strongest realistic alternative at sign-off, configured by someone who wants it to win.
Results are selected after the fact
Early signalOnly some runs, metrics or datasets appear in the report.
MitigationAgree the analysis in advance and report every run, including those that failed.
Findings never reach engineering
Early signalThe report is accepted, praised and filed.
MitigationName who builds next before the findings phase and put integration constraints in the transfer package.
Why a negative result is a deliverable, not a failure
Research can return "no", and an engagement that cannot accept that answer is an engineering project with a research label. A well-designed negative result is specific: the approach did not beat the baseline on these tasks, under these conditions, by more than run-to-run variance. That closes a door with evidence, protects a budget from a plausible but unproven idea and tells the next team which conditions remain untested.
For that to work, the negative result is defined before experiments begin, in the same terms as the metric. Our R&D brief guide shows how to write it down, and the page on IP and publication terms covers whether a negative result can be shared with others who would otherwise repeat the work.
Frequently asked questions
How does commissioned research differ from a vendor proof of concept?
A proof of concept is built to show that something can work; research is designed so that it could show the opposite. The baseline, the metrics and the negative result are agreed before experiments run, and every run is reported, including the failures. If the evidence says an approach does not help, the report says so plainly.
Can you replicate a published result before we build on it?
Yes. Replication is a well-bounded research question: the paper supplies the method and the claimed effect, and the study tests whether it holds on your data, hardware or workload. Replications often surface conditions the original authors did not test, which is what an engineering team needs to know before committing. The brief names the result and what would count as failing to reproduce it.
Do you take on research questions outside the six listed areas?
Sometimes, when a question sits next to one of them, such as evaluating retrieval systems or cryptographic protocol design beyond signatures. If it needs expertise we do not hold, we say so and either propose a named academic collaborator for you to approve or point you to someone better placed. We would rather decline than run research we cannot evaluate properly.
Can experiments run inside our own environment with our data?
Yes, and for sensitive data it is often the better arrangement. Experiments can run on infrastructure you control, with researchers given scoped access, so data never leaves your environment. The reproducibility requirements still apply: environments are pinned, runs are logged and results retained, which needs some coordination with your platform team during set-up.
How do checkpoints protect the research budget?
Each phase ends with a readout compared against the signed brief, and the sponsor decides whether to continue, narrow the question or stop. Where phases carry their own fees, stopping ends spending on a question the evidence has already settled, or shown to be unanswerable with the data available. Stopping on a pre-agreed rule is a normal outcome, not a breach of the engagement.
Is a technical report enough for an investment committee?
It is written to be: alongside method and results it carries limits on confidence, recommended next steps and a summary for non-specialists. What it does not provide is certification or regulatory approval, which need accredited bodies. Committees typically use it to choose between funding a prototype, more research or nothing, and the stated limits tell them how much weight it can bear.
Sources