Partners / Testers
Help us test what we build.
Help us test what we build.
Some problems appear only when a product, tool, or explanation meets a real person, workflow, device, or technical environment. inAi opens selected testing opportunities when outside use can answer a concrete question and improve the work before it reaches more people.
Testing is not continuously open across everything we build. Tell us where your experience is relevant. If your context matches a suitable opportunity, we may invite you; the invitation will state the scope, expected commitment, and conditions before you decide whether to participate.
Where testing can help
What we test changes with the work and its maturity. Depending on the question, an opportunity may involve one of the following areas.
Products and real workflows
Selected product flows, onboarding, outputs, review steps, and whether a product fits the task it is intended to support. Depending on stage, this may include invited PageMind workflow testing, pre-launch Emplo testing, or future inAi products.
Open Source and technical tools
Installation, compatibility, documentation, examples, error handling, and reproducibility across real environments. For a public repository, the relevant GitHub issue tracker is usually the best place to begin.
Software for agents
Agent-facing tools and documentation, structured inputs and outputs, state, recovery, and whether a workflow is usable by an agent or by the developer configuring it. This applies where a public or invited test exists.
Public pages and explanations
Readability, accessibility, navigation, forms, and whether an explanation makes sense to the people it was written for. This can include AI for Everybody, AGI and Research pages, product pages, and the wider inAi website.
Found something public already—a broken link, unclear page, form problem, or issue in a public repository? You do not need an invitation to report it.
Who can be useful
The right tester is not always the most technical person.
A professional may understand the workflow a product is meant to improve.
A developer may reproduce a problem in a particular environment.
A first-time user may expose assumptions the team no longer notices.
A job seeker or nontechnical reader may show where an experience becomes confusing or stops feeling useful.
What matters is a relevant perspective, candid feedback, and the ability to explain what happened. We value people who will tell us when something works, when it does not, and why.
Useful testers can:
describe the real context in which they are testing;
distinguish personal preference from a broken or unclear experience;
report enough detail for the issue to be understood;
work within the agreed scope;
respect privacy and confidentiality where they apply.
How testing works
1. Tell us your context
Describe what you are interested in testing, the workflow or environment you know, and the kind of feedback you can provide.
2. We look for a match
We contact people when their context fits a concrete testing question and the work is ready for outside use.
3. You receive a test brief
The invitation explains what is being tested, what you would be asked to do, the expected time, and the conditions that apply.
4. You decide whether to take part
Receiving an invitation does not create an obligation. Participation begins only after you understand and accept the scope.
5. You test and report
You complete the agreed activity and submit feedback through the route described in the brief. Follow-up happens only where it is useful to the test.
Registering interest does not guarantee selection, access, or an individual reply. It gives us a way to find relevant people when a suitable opportunity opens.
A clear exchange
Testing should be a clear exchange. inAi provides a defined question, an honest description of the work’s maturity, the necessary instructions and access, and a contact point. The tester provides time, real use, and candid feedback.
Before an invited test begins, we will explain, where relevant:
what is being tested and what we are trying to learn;
what you will be asked to do and how much time is expected;
how access, setup, devices, or technical environments are handled;
what data may be used and whether activity is recorded or logged;
whether confidentiality or an embargo applies;
whether the test includes compensation, early access, recognition, another specific benefit, or none of these;
how feedback should be submitted and where to ask questions.
Feedback informs our decisions, but it does not guarantee that every suggestion will be implemented or that access will continue after the test.
What useful feedback looks like
Useful feedback gives us enough context to understand what happened and decide what to investigate next.
A strong report usually includes:
what you were trying to do;
what you expected to happen;
what happened instead;
the device, browser, operating system, repository, tool version, or environment where relevant;
whether the result can be reproduced;
why the issue matters in practice.
Example
On mobile Safari, the form accepted my details but showed no confirmation after submission. I repeated the flow twice and could not tell whether the message had been sent.
A suggested fix is welcome, but it is not required. A precise description of the problem is already useful.
Use the least sensitive data that can test the point
Begin with a description, a public example, a synthetic sample, or anonymized material whenever possible.
Do not send passwords, credentials, API keys, private customer, supplier, or candidate data, confidential documents, proprietary datasets, or security exploit details through a general tester form.
If an invited test needs additional material, we will agree on the route and boundaries before anything is shared. For security-sensitive findings, use the security reporting information provided in Legal rather than a general testing route.
Testing or another kind of collaboration?
Testing is the right route when you want to try a product, tool, workflow, or public experience and report what happens. Another route is usually better in the following cases.
Waitlists
Use a product waitlist when you only want updates or future access. A waitlist records interest; it is not participation in a defined test.
Pilots / Corporate partners
Use this route when a company or institution wants to evaluate a product inside a real operational workflow, with organizational data, stakeholders, constraints, and a defined outcome. This is usually the better route for organizational PageMind evaluation.
Contributions
Use Contributions—or the relevant GitHub repository—when you want to submit a change to public code, documentation, examples, or another public artifact.
Work with us or Internships
Use the relevant page when you are looking for an ongoing working relationship or a structured, time-bounded learning placement.
Academia / Research
Use this route when the intended result is a formal study, evaluation, publication, research method, or longer research collaboration.
Tell us what you can test
Your first message should be short and specific. Include:
the product, tool, public page, or type of experience you are interested in;
the workflow, role, or perspective that makes your context relevant;
your device or technical environment, if it matters;
your approximate availability.
Do not attach sensitive material at this stage. We may contact you when your context matches a concrete testing question.