Agent-era developer infrastructure
Tools that help AI-assisted workflows become more controlled, inspectable, and reviewable — including MCP-style surfaces and local automation utilities.
OpenOpen Source / Approach
Our Open Source Approach
Selected AI tools, shared when they can help beyond inAi.
Why we release tools in the open
AI-native software is not built only behind closed product pages. Useful tools often begin as experiments, developer utilities, local workflows, prototypes, or operating surfaces that can help other builders long before they become polished products.
inAi releases selected tools in the open when they are useful beyond our own work, understandable from the repository, and safe to share publicly. Some projects support products we are building. Some explore agent-era interfaces, local-first workflows, AI media generation, speech, conversation, or operating surfaces. Some are older reference projects kept public because they still contain useful ideas.
Open Source is not the whole company, and it is not a promise that every internal system will become public. It is one part of how inAi brings AI to the real world: by releasing practical tools where openness creates value, while keeping private product systems, sensitive data, security-sensitive infrastructure, and internal architecture protected.
AI is becoming a new operating layer for software and work. That shift will not be shaped only by finished products. It will also be shaped by tools, interfaces, prototypes, local utilities, developer workflows, experiments, and public reference implementations that help people understand what is possible.
When a tool can be useful outside inAi, we prefer to let people inspect it, run it, adapt it, learn from it, or contribute to it. Open Source lets useful work travel farther than a private repository. It gives developers and researchers something concrete to examine. It gives technical partners a clearer sense of how we build. It gives the wider ecosystem more material to work with.
With the community, for the community, alongside the community
Open Source is not just a publishing channel. It is a way to work with the people who build, test, inspect, extend, and question technology.
We release selected tools because other people may find uses we did not predict. Developers may improve a workflow. Researchers may inspect an implementation detail. Users may adapt a utility to their own local process. Partners may see a starting point for collaboration. Contributors may help move a project forward or identify where a prototype needs to be more robust.
This community posture does not require pretending that everything is public or fully mature. It requires clarity: what the project does, what state it is in, how it can be used, what is experimental, what is legacy, and where collaboration makes sense.
What we release
inAi's Open Source work spans several kinds of AI-native software. Some projects are developer infrastructure for agent-era workflows. Some are local-first applications that help people run AI tasks on their own machines. Some explore creative or media workflows. Some experiment with speech, translation, conversation, or wearable interfaces. Some preserve older AI workflow prototypes and utilities because they remain useful references.
The common pattern is not a single product type. The common pattern is usefulness: tools that can help people build, inspect, automate, prototype, learn, or work with AI systems more directly.
How we choose what to release
Not every internal tool should become public. Some tools are too tied to private product systems. Some contain sensitive implementation details. Some depend on customer, supplier, candidate, or partner data. Some are useful only inside inAi. Some need more cleanup before anyone else can understand or run them.
This is why our Open Source portfolio contains a mix of active tools, experiments, reference utilities, and legacy projects. Openness is valuable when it creates value. Control is necessary when control protects users, partners, products, or sensitive systems.
- It can be useful beyond inAi.
- It can be understood from the repository.
- It can be separated from private product internals.
- It does not expose customer, supplier, candidate, or private operational data.
- It does not expose security-sensitive infrastructure.
- It can be labeled honestly by maturity.
- It may benefit from inspection, reuse, contribution, or public reference.
- It helps the wider AI ecosystem move forward in a practical way.
How to read project labels
Every project in the Open Source portfolio should be read through its status label. The label is not decoration. It tells visitors what kind of repository they are looking at and what expectations are reasonable.
Some projects are active. Some are experimental. Some are useful references. Some are older prototypes that remain public because they show an idea, workflow, or implementation pattern worth preserving.
Clear labels let us release more work without pretending that every repository has the same purpose. They also make the portfolio more useful: a developer can decide whether to run, inspect, adapt, or simply learn from a project based on its current state.
Owned projects and ecosystem work
The Open Source portfolio page lists inAi's owned public projects: repositories we maintain and present as part of the inAi Open Source category.
That is different from ecosystem contributions. AI-native software depends on shared infrastructure: search and retrieval, model gateways, provider interfaces, tooling, protocols, developer workflows, and other open building blocks. When inAi contributes to external projects or ecosystem infrastructure, those contributions should be described separately from owned repositories.
The distinction matters. Owned projects are part of inAi's public portfolio. Ecosystem contributions are participation in broader infrastructure that many AI builders may depend on. Both can matter, but they should not be presented as the same thing.
Open tools for the agent era
A growing part of AI software is not built only for humans clicking screens. Agents and AI-assisted workflows need tools they can call, inspect, reuse, and operate with clearer boundaries.
That is why Open Source connects naturally to Products for Agents. Public tools can expose how agent-era workflows may work: callable surfaces, structured actions, local execution, reviewable outputs, job status, diff inspection, safety gates, and explicit boundaries around what the system is allowed to do.
`codex-mcp-wrapper` is the strongest current public bridge between these two areas. It remains an Open Source project first, but it also shows the kind of agent-era tooling inAi cares about: software that AI-assisted workflows can use in a more controlled, inspectable, and reviewable way.
Open Source as practical research surface
Research can become too abstract if it never touches working software. Open Source gives some ideas a concrete surface: a repository, a workflow, a prototype, a utility, or a tool that people can inspect.
That does not mean every Open Source project is a research result. It means public tools can support the broader research culture around AI-native systems, agentic workflows, local-first software, interface design, and practical AI operations.
For inAi, this matters because our view of intelligence is systemic. Models, tools, memory, execution, feedback, interfaces, and environments all matter. Open Source can expose selected pieces of that broader software world without turning private architecture into public material.
Public tools can also teach
Open Source is not only for people who already know exactly what they are looking for. Public repositories can also help people learn how AI tools are built, where their limits are, and why maturity matters.
That connects Open Source to AI for Everybody. The public conversation around AI is often too abstract, too fearful, or too promotional. Real tools make the conversation more concrete. They show that AI software is not magic: it has interfaces, inputs, outputs, state, permissions, logs, failures, retries, and design choices.
Not every reader will inspect code. But even clear project pages, honest labels, and simple explanations can help more people understand how AI moves from research or demos into practical software.
Open where openness creates value
Open Source is one way to build trust, but it is not the only one. Some trust comes from public code, clear labels, and inspectable tools. Some trust comes from product boundaries, privacy, legal documents, evidence, review, or controlled access. Different kinds of AI software need different trust patterns.
Our Open Source posture follows the same principle: release selected tools where openness creates value, and keep private what should remain private. Product internals, sensitive data, security-sensitive infrastructure, and internal architecture do not become public simply because inAi has an Open Source category.
The goal is not maximum exposure. The goal is useful openness with clear boundaries.
Each repository includes its own license and usage details on GitHub.
Contribute, inspect, or collaborate
There are several ways to engage with inAi's Open Source work.
You can inspect repositories, run tools where appropriate, open issues, suggest improvements, or contribute when a project is suitable for outside collaboration. You can also contact inAi if you see a connection between our Open Source work and your product, research, institution, developer workflow, or technical partnership.
Not every project has the same contribution model. Some are active. Some are experimental. Some are reference or legacy projects. The repository status and README should guide expectations.
Open Source is one part of the system
inAi is building an AI-native product company for the intelligence era. That means products for businesses, consumers, agents, and open ecosystems. Open Source is one of those categories because useful AI-native software should not exist only as private demos, closed pages, or internal utilities.
Some tools should become products. Some should become public projects. Some should remain research. Some should stay private. The important thing is to choose deliberately.
For inAi, Open Source is where selected public work can help others build, inspect, learn, and collaborate — while the company continues to build products, research intelligence as a system, explain AI for everybody, and bring AI into the real world.