Partners
Academia / Research
Research collaboration around intelligent systems, agents, evaluation, knowledge creation, AI-native software, and the real-world use of AI.
inAi is an AI-native product company with a research layer. We consider collaboration with universities, laboratories, research groups, professors, doctoral and graduate researchers, and independent researchers when a specific question benefits from both research discipline and practical product or systems context.
A good collaboration begins with a clear question, a plausible method, a defined contribution from each side, and an output worth producing. The purpose is to create knowledge, evidence, methods, prototypes, tools, or explanations that remain useful beyond a promotional claim.
Research with a product company
AI systems become meaningful when models connect with tools, memory, interfaces, execution, feedback, and the environments in which people and organizations use them. That creates questions that cannot be answered by model benchmarks or product marketing alone.
inAi’s role is different from a university’s. We can contribute systems thinking, questions emerging from products and operational work, engineering and prototyping where feasible, selected public technical work, and a route between research, product design, Open Source, and public explanation. Academic partners contribute methodological depth, disciplinary knowledge, institutional governance, supervision, and publication pathways.
The exact exchange is defined project by project. Product access, data, compute, engineering time, funding, and private materials are never assumed merely because a research conversation has begun.
Who this route is for
Universities, laboratories, and research groups
Teams studying AI, intelligent systems, agents, software, human–AI interaction, knowledge work, evaluation, organizational change, or related fields.
Professors, doctoral researchers, and supervised students
Researchers proposing a thesis, capstone, doctoral project, supervised study, review, experiment, or other academically governed collaboration.
Independent and applied researchers
People with credible prior work, relevant expertise, and a specific proposal. Institutional prestige is not the standard; the quality, clarity, and feasibility of the work are.
Start with the public research layer
Our public research layer currently includes our systems stance on AGI and four research directions. Related product theses, Open Source work, and AI for Everybody provide additional contexts for research and public explanation. AGI is a research horizon and systems stance here, not a claim that inAi has AGI or that any current product is AGI.
A research direction is not automatically a published paper, and a prototype is not automatically validation. When inAi publishes research outputs, they should be labelled by what they are: a peer-reviewed article, preprint, research note, technical report, protocol, benchmark, experiment, software artifact, or public explainer.
Questions we can investigate together
inAi organizes its public research around four directions. A proposal does not need to cover an entire direction, but it should identify a question precise enough to investigate.
Limits of Intelligence
Where do current AI systems succeed, and where do their limits become visible once work extends beyond a single response?
Relevant questions include how errors compound across tool use, memory, and execution; how uncertainty should be represented; how long-running or multi-step work should be evaluated; when orchestration improves performance and when it only adds complexity; how systems recover after an incorrect intermediate action; and how evaluation can distinguish model capability from system capability.
Agentic Decision Systems
How should agents choose what to do, which tools to use, when to ask, when to stop, and how to recover when a step fails?
Relevant questions include planning and replanning, tool selection, state and memory, permissions, escalation, review, interruption and continuation, error recovery, multi-agent or multi-component coordination, and the design of software that an AI agent can understand and operate rather than merely view through a human interface.
AI for Knowledge Creation
How can AI assist research, writing, synthesis, analysis, and explanation without flattening disagreement, losing provenance, or manufacturing certainty?
Relevant questions include literature review, source-grounded synthesis, hypothesis generation, contradiction detection, research-gap identification, replication support, human–AI division of labour, disclosure of substantive AI involvement, and methods for evaluating accuracy, novelty, traceability, and usefulness in AI-assisted knowledge work.
AI and Business Operations
How should AI be designed and evaluated inside real organizational workflows, where information is incomplete, processes are inconsistent, and outputs must be usable by people and systems?
Relevant questions include measuring value in operational settings, deciding which tasks should be automated, assisted, prepared, or left manual, understanding how AI changes handoffs and review, evaluating decision quality and adoption, preserving evidence and provenance, and identifying the practical limits of agentic automation in business environments.
Cross-cutting work may also address human–agent interaction, AI-native software, agent-readable documentation, public AI understanding, Open Source research tooling, reproducibility, and the design of systems that expose evidence, state, permissions, review, and recovery clearly.
Ways collaboration can take shape
Research collaboration does not have one standard format. The right structure depends on the question, the people involved, the required resources, the expected output, and the institutional context.
Exploratory research conversations
A collaboration may begin with a focused discussion of a research question, paper, method, evaluation problem, research direction, or product-facing implication. An early conversation is useful when the subject is specific enough to assess but the project form is not yet settled.
Joint research and independent evaluation
inAi may participate in a jointly designed study, or provide a suitable context for independent evaluation or critique. Independent work must remain genuinely independent: the purpose is not to produce an endorsement, and the findings may support, refine, challenge, or reject an assumption.
Thesis, capstone, and doctoral work
A student project may fit when it has a responsible academic supervisor, a clear educational and research purpose, a scope that matches the academic calendar, and agreed expectations around access, confidentiality, examination, publication, authorship, and intellectual property.
Use the Internships route when the primary purpose is practical work experience or a placement rather than an academically supervised research question.
Research prototypes, benchmarks, and Open Source tooling
Some questions are best explored through a working prototype, evaluation harness, benchmark, documented experiment, reference implementation, or Open Source tool. The project should define what is being tested, who will maintain the artifact, and whether code, data, methods, or documentation can be released publicly.
Papers, notes, reports, and public explanation
A collaboration may produce a paper, preprint, research note, technical report, evaluation framework, protocol, workshop, public talk, or accessible explainer. The form should match the work. Not every useful result needs to be presented as an academic paper, and non-peer-reviewed work must not be described as peer reviewed.
Grants and funded research
Research may be supported through partner funding, sponsored work, public funding, a grant, a consortium, in-kind contribution, or a mixed model. Use the Grants route when the funding programme, eligibility, consortium, work packages, budget, or reporting framework is the primary starting point.
What each side can bring
inAi may contribute
Research questions emerging from AI-native products, agent-facing software, operational workflows, Open Source work, and public explanation.
A systems-level perspective connecting models, agents, tools, memory, interfaces, execution, coordination, feedback, and environment.
Product, software, workflow, and implementation context that can test whether an idea survives outside an isolated demonstration.
Engineering, prototyping, research tooling, or technical review where the project and current capacity make that realistic.
Relevant public repositories, documentation, research pages, product theses, or scoped access to a product or prototype when it is feasible, authorized, and necessary for the study.
Product-side interpretation of findings and, where appropriate, a path to public dissemination through Research, Open Source, News, or AI for Everybody.
The exact contribution from each side must be agreed before substantive work begins. The following are possible contributions, not standing promises attached to every inquiry.
A research partner should bring
A clear research question, relevant literature or prior work, and a plausible method.
The disciplinary, technical, qualitative, quantitative, or design expertise needed to conduct the work responsibly.
A responsible principal investigator, supervisor, or project lead where the project requires one.
Research time, project management, and institutional support appropriate to the proposed scope.
Ethics review, participant governance, data rights, facilities, compute, funding, or other resources where the method requires them.
A defined output and a precise account of what is being requested from inAi.
How we handle research
Independence and useful results
Research should be capable of changing what either side believes. A project may support an inAi assumption, refine it, expose its limits, produce an inconclusive result, or show that a proposed approach does not work. Negative and inconclusive findings can still be useful research outputs.
An evaluation is not expected to become a product endorsement. Where publication is part of the project, a rigorous result should not be blocked merely because it is inconvenient to either side, although legitimate confidentiality, privacy, intellectual-property, and security constraints must be respected.
Methods and accurate labels
A serious project should state its question, method, relevant baselines, data or participants, models and system versions, evaluation criteria, known limitations, and any material changes made during the work.
For agentic or multi-step systems, one-response evaluation may be insufficient. Depending on the question, the method may need to examine decision sequences, state, memory, tool use, recovery, human intervention, cost, latency, and the quality of the final outcome.
When AI tools materially affect literature review, coding, analysis, synthesis, or writing, their role, relevant version, human verification, and limitations should be disclosed where appropriate.
Public outputs should be labelled accurately. A company note is not a peer-reviewed paper. A prototype is not a proven product. A benchmark is not a complete account of real-world performance.
Publication, authorship, and conflicts
Publication expectations, review periods, authorship, acknowledgements, institutional naming, funding disclosure, and conflicts of interest should be discussed before the work begins.
Authorship follows substantive contribution. Funding a project, providing access, or supplying a product context does not automatically create authorship. Institutional names and logos must not be used as endorsements unless the relevant parties have explicitly agreed.
A research discussion must not be announced publicly as a partnership before both sides have approved that description.
Data, ethics, and access
The first contact should be non-confidential. Do not send personal data, confidential datasets, unpublished institutional material, proprietary code, or other sensitive information in the initial message.
Projects involving people, personal data, interviews, education, employees, students, job seekers, user testing, or behavioural observation may require institutional ethics review, informed consent, an appropriate legal basis, access controls, retention rules, and a clear allocation of responsibility.
Access to products, code, datasets, compute, internal environments, or engineering support is considered only when it is feasible, authorized, necessary for the research question, and covered by the appropriate agreements. Some material will remain unavailable.
Intellectual property, confidentiality, and funding
Before substantive work begins, the parties should distinguish pre-existing inAi work, pre-existing academic or partner work, third-party code or data, and results created through the project. The agreement should address publication rights, research-use rights, software and data ownership, licensing, Open Source release where appropriate, confidentiality, and any commercial use of the results.
Projects may be in-kind, partner-funded, grant-funded, sponsored, or supported through a mixed model. A proposal should state whether funding exists, is being sought, or is requested, and identify material costs such as researcher time, institutional overhead, compute, model usage, software or data licences, participants, travel, equipment, publication, or maintenance.
From proposal to project
1. Initial fit review
inAi reviews the question, its connection to the company’s research and product work, the proposed method and output, the requested contribution, feasibility, current capacity, and the relevant public/private boundaries.
2. Non-confidential discussion
If there is potential fit, the first conversation clarifies the question, why collaboration is needed, who would participate, what each side may contribute, and which constraints need to be understood early.
3. Concept note and scope
The parties define the research question, method, responsibilities, access, resources, funding, timeline, expected outputs, publication expectations, and criteria for continuing, changing, or stopping the work.
4. Institutional and legal alignment
Where required, the relevant research office, supervisor, ethics body, data-protection contact, legal representative, funder, procurement team, or authorized signatory is involved before work begins.
5. Research and review
The project proceeds with named leads, agreed milestones, documented methods, version control where relevant, a communication rhythm, and a process for scope changes or material issues.
6. Output and next decision
Before publication or release, the parties verify claims, resolve confidentiality and intellectual-property review, disclose funding and conflicts, label the output accurately, and decide whether the work should continue into further research, a product project, a pilot, an Open Source release, or no further activity.
Submitting a proposal begins a fit review. It does not by itself create a partnership or commit either side to funding, access, supervision, authorship, publication, or public announcement.
What to include in a proposal
A useful first message should include:
Your name, role, institution, laboratory, research group, or independent-research profile.
Links to relevant publications, projects, repositories, profiles, or previous work.
The research question or problem and why it matters.
The inAi research direction, product context, Open Source work, or public layer that makes inAi relevant.
The proposed method, including any required data, participants, software, models, evaluation setting, or research infrastructure.
The collaboration format you are proposing and the expected output.
What you or your institution will contribute and what you are asking inAi to contribute.
The intended start, duration, important academic or funding deadlines, and any target publication venue if one exists.
The funding status: funded, funding sought, sponsorship requested, in-kind, or not yet determined.
Any known ethics, privacy, confidentiality, publication, intellectual-property, or Open Source considerations.
A concise first message or a one- to two-page concept note is enough. Use links where possible. Do not send confidential material or large unsolicited attachments before basic fit has been established.
Make sure this is the right route
Use Academia / Research when the primary purpose is to create knowledge, evidence, a method, an evaluation, or another research output.
Use Internships when the primary purpose is a supervised learning and work placement.
Use Contributions when the main goal is to improve a public repository, document, explanation, or other public artifact.
Use Testers when the main goal is structured feedback on something that already exists.
Use Pilots / Corporate partners when the main goal is to evaluate a product or repeatable product direction inside a real organizational workflow.
Use AI Services when the main goal is to design or build a custom system for one organization.
Use Grants when the funding programme, consortium, budget, eligibility, or funded deliverable is the primary starting point.
Use Work with us when the goal is an ongoing employment, contract, or continuing working relationship.
Before contacting us
Do not use inAi’s name in a grant application, paper, public post, partnership announcement, or institutional communication before both sides have agreed to that use.
Generic mass outreach, pay-to-publish solicitations, requests for confidential access, and proposals designed only to create an endorsement are not research collaboration proposals.
Propose a research collaboration
Send a concise, non-confidential message to research@inai.world.
Suggested subject line: Research collaboration — [topic / institution]
A clear question is more useful than a broad institutional introduction. Explain what you want to investigate, why inAi is relevant, what you can contribute, what you need from us, and what output you believe the work could produce.