Testers

Help test inAi’s work

inAi builds AI-native products and open technology for the intelligence era.

Some work can be understood from strategy. Some can be explained in research. Some can be shown through public repositories. But products become real when they meet real people, real workflows, real data shapes, real edge cases, real devices, real confusion, and real expectations.

This page is for people and teams who want to help test inAi’s work.

Testing can mean many things: trying a product before wider release, reporting a broken flow, testing an Open Source repository, giving structured feedback on a career workflow, checking whether an AI explanation is understandable, reviewing agent-facing documentation, or helping us see where a product makes sense in the real world.

Testing is not a guarantee of access, employment, payment, partnership, product launch, or public availability. It is a serious feedback path for people who want to help inAi improve what it builds.

Why testing matters to inAi

inAi is not building around one app, one workflow, or one isolated feature.

The company works across business products, consumer products, Products for Agents, Open Source, AGI / Research, AI for Everybody, Trust, and public website infrastructure. Those layers are connected by one thesis: AI is becoming a new operating layer for software and work, and inAi exists to bring that layer into real products and systems.

Testing is where that thesis becomes practical.

A product can sound correct in writing and still fail in use. A tool can be powerful and still be hard to install. A page can be accurate and still be unclear. A career assistant can be useful in theory and still miss what job seekers actually need. An agent-facing tool can expose a callable interface and still be uncomfortable for agents or developers to operate. A contact route can exist and still send people to the wrong place.

Testing helps us close that gap.

Testing is not decoration. It is how the public architecture becomes usable.

What makes feedback useful

Useful feedback is specific enough to act on.

A strong tester report usually includes what you were testing; the page, product, repository, form, or workflow involved; what you expected; what happened instead; device, browser, operating system, environment, or tool version where relevant; steps to reproduce; screenshots only if they do not expose private data; sample files only if public, synthetic, or explicitly safe; why the issue matters; and your suggested fix if you have one.

What testers can expect

Testing access depends on the product, page, project, and maturity stage.

Some testing is public: reading pages, reporting broken links, reviewing Open Source repositories, opening GitHub issues, checking documentation, testing public forms, and giving general website or explanation feedback.

Some testing is selected: PageMind product tests, Emplo waitlist / pre-launch tests, Products for Agents private alpha or internal-use candidate testing, company workflow tests, structured feedback sessions, research-adjacent review, and institutional or partner testing.

Some testing may require a short screening conversation, a specific use case, a safe test dataset, a company or institutional context, an NDA or confidentiality terms, consent for feedback processing, or a controlled pilot or partner path rather than a public tester route.

What to send

A good tester message should be short, structured, and specific.

Include who you are; what you want to test; your testing context; what you can provide; technical environment if relevant; availability; data boundary; and relevant links.

Example: I would like to test Products for Agents documentation and agent-facing tool workflows. I am a developer working with AI automation and MCP-style tools. I can test setup instructions, tool descriptions, example prompts, and whether the documentation is clear enough for agent-assisted use. I can provide one structured report per week for one month. I will not send private customer data.

Example: I am a job seeker interested in Emplo. I can test whether the waitlist flow, value proposition, and user-control language are clear. I can give feedback from the perspective of someone applying for internships and entry-level roles. I am not asking for job guarantees or automatic application sending.

Example: I work with product data and catalog enrichment in retail. I would like to test whether PageMind matches the workflow we actually have: supplier PDFs, images, product attributes, multilingual descriptions, and export into catalog templates. We can discuss whether this should be a pilot route rather than a tester route.

Testing and trust

Testing requires trust in both directions.

inAi needs useful feedback without receiving unnecessary private data. Testers need to know that the company will not pretend early testing means public launch, guaranteed access, or unrestricted automation.

The principle is simple: Use the least sensitive data that can test the point.

For PageMind, that may mean describing a catalog workflow before sending any file. For Emplo, that may mean reviewing copy or onboarding before sharing personal career material. For Open Source, that may mean reporting environment errors without exposing private system details. For Products for Agents, that may mean testing documentation or tool behavior without exposing private prompts, credentials, or internal systems. For AI for Everybody, that may mean reviewing readability rather than debating every frontier-lab claim.

Testing is not a job application

Testing can sometimes lead to a deeper relationship, but it is not the same as work, employment, internship, contracting, or investment.

If you want to work with inAi, use Work with us. If you want an internship, use Internships. If you want to contribute public work, use Contributions. If you want to test products or pages, use this page.

You can mention multiple interests in one message, but the more specific you are, the easier it is to route correctly.

How to contact inAi about testing

Use Contact when available and choose the route closest to testing.

Suggested contact route: Contact -> Testing / early feedback.

If a general email route is needed, use contact@inai.world.

Suggested subject line: Tester interest — [Area] — [Your name].

For company pilots, use partnerships@inai.world with subject line Pilot testing — [Company / workflow] — [Your name].

For research-page or academic testing, use research@inai.world with subject line Research feedback — [Topic] — [Your name].

Related pages