The latest platformOS Town Hall brought together platform updates, live demonstrations, and a partner-built product to explore a question that is becoming increasingly practical: what changes when AI becomes part of both the development process and the applications being built?
Across three different demonstrations, the session showed this shift at multiple levels.
Adam Broadway demonstrated how MCP-based AI capabilities can operate inside a platformOS application while respecting its existing roles and permissions. Scott Reynolds presented an AI-powered course creation application built on platformOS, illustrating how AI is changing the traditional build-versus-buy equation. platformOS CTO, Maciek Krajowski then went under the hood, sharing the platform and developer tooling improvements being made to support AI-assisted development more broadly.
Together, the demos showed AI augmentation moving beyond experimentation and into practical development workflows.
The Town Hall opened with a live demonstration using the platformOS Community solution.
Starting from a new instance, Adam deployed the Community Solution with an MCP server built right into the application, so AI agents could work with it directly, without any separate system in between. The goal was not simply to demonstrate an AI agent interacting with platformOS, but to show how AI-powered functionality can operate within the same rules that govern the application itself.
The MCP module being developed by the platformOS team allows developers to expose specific tools to AI, and those tools follow the same rules as the rest of the application. Roles, permissions, and other guardrails already built into platformOS apply to AI agents just as they do to any other user.
This distinction becomes increasingly important as AI moves from answering questions to taking actions.
In the demonstration, the AI agent acted on behalf of Adam, a regular user of the Community application, as if he were logged in himself. Using the MCP tools, it generated the event information and image, then published the event with exactly the same functionality and rules available to Adam in the application's interface. It could do nothing more than Adam himself could do.
The important point was not the event itself, but the boundary around the AI.
Instead of giving an agent unrestricted access to an application or its underlying infrastructure, developers can define the actions available to it and connect those actions to the application's existing authorization model. The same approach could be applied to content workflows, internal business processes, customer-facing tools, or other application-specific operations.
The pos-module-mcp demonstrated during the session is still in development and is planned for release as an official platformOS module.
Scott Reynolds of Thrise and HR Jetpack approached the topic from a different direction.
His starting point was a familiar software decision: should you build something yourself or buy an existing product?
Buying is often the sensible choice when an existing product already does what an organization needs. The problem arises when the available software almost fits. Teams can end up adjusting workflows and even business decisions around the limitations of a product they do not control.
Scott summarized the alternative with a principle that has guided his team's use of platformOS: tools should bend to the organization, rather than forcing the organization to bend to the tools.
He illustrated this with two applications his team had already built on platformOS.
The first was a simple teleprompter. After trying multiple off-the-shelf tools that did not fit their production workflow, the team built exactly what they needed and integrated it with their learning management system.
The second was much more ambitious: their own LMS. Building it required significantly more effort, but it also gave the company a system that could evolve alongside the business instead of constraining it to the assumptions of an existing product.
Until recently, however, there was still a practical limit. Some applications were simply too complex to justify building.
AI is beginning to move that boundary.
Scott's main demonstration was what his team currently calls Course Creator, an AI-powered course editing application built on platformOS.
The idea came directly from years of producing self-paced educational content. Traditional video editing applications can support many kinds of content, but they do not inherently understand that the user is creating a course.
Course Creator is designed around that context from the beginning.
The application works with information about the course, instructor, brand, script, slides, and other course-specific elements. AI then becomes another way of interacting with this context-aware environment.
During the demonstration, Scott selected sections of a course script and gave the application natural-language instructions. He asked it to add a lower third, change its content and appearance, create bullet points synchronized with spoken words, and generate a slide emphasizing key ideas.
Because the application understands the surrounding context, these commands can involve more than generating isolated elements. When a slide was introduced, for example, the application moved the instructor on screen to avoid covering them. When asked to add a subtitle, it understood the relationship between the new element and an existing title. For more complex instructions, the AI could create a multi-step plan before executing it.
Importantly, the interface does not assume that AI must perform everything.
Users can make manual changes, use traditional editing controls, or ask AI to perform an action. The expected workflow is a combination: sometimes direct manipulation is faster, sometimes AI is more useful, and often the two work together.
Scott described Course Creator as an application he "wouldn't have, shouldn't have, couldn't have built a year ago."
That does not mean complex software has suddenly become effortless. Course Creator is still under active development, and the demonstration included examples where AI output required adjustment. The application also draws on the team's long experience in course production and their understanding of the workflow they are trying to improve.
Instead, the example shows how domain expertise, experienced developers, AI models, and platform-level tooling can work together to make specialized software more practical to build.
For platformOS partners, that can change the starting question. Rather than asking only whether an existing SaaS product is close enough to a client's requirements, teams can increasingly consider whether a purpose-built solution is realistic.
The final section of the Town Hall moved from applications back to the development environment itself.
CTO Maciek Krajowski presented a series of platform and CLI updates intended to make AI-assisted development easier and more reliable.
A central change is pos-cli ai init, designed as an entry point for platformOS AI tooling. The command configures the MCP servers required for the current AI development workflow, including access to pOS CLI tools and the platformOS Supervisor. Supervisor, previously available as a standalone tool, is now included with pOS CLI 6.2.
The Supervisor provides platform-specific knowledge and guidance while an AI agent is working. Scott described the combination during his presentation as involving three layers: an experienced developer directing the work, the platformOS Supervisor contributing platform-specific knowledge and best practices, and a frontier model carrying out development tasks.
The aim is not autonomous development without oversight, but to give AI better context about the environment in which it is operating.
Several technical updates presented during the session follow the same principle.
Error reporting has been improved so logs can include the line of code that generated an error as well as a stack trace. This helps developers debug issues while also giving AI agents better information when diagnosing problems. The team plans to continue this work across errors originating from pages, background jobs, and other parts of an application.
Liquid is also being adapted to patterns that AI coding agents naturally tend to produce. Multi-line syntax support has been expanded beyond render to other tags, and JSON literal arguments have been introduced for function calls.
Rather than repeatedly teaching an AI agent to avoid otherwise common coding patterns because the platform does not accept them, platformOS is removing some of that friction where appropriate.
It is a subtle but important shift: making the development environment not only usable by humans, but more predictable for the AI tools working alongside them.
The Town Hall also included several updates to modules and migration tooling.
pos-cli modules install has been improved to resolve local dependencies and module versions more reliably, supporting workflows where external modules are kept out of version control while the lock file remains the source of truth.
A new push notifications module, already used by the platformOS Community site, is now available, while a CAPTCHA abstraction module supports multiple providers without requiring applications to rewrite the surrounding implementation.
For Dedicated Private Stack migrations, the new pos-cli dns migrate command can copy DNS records between Partner Portals rather than requiring them to be transferred individually. Further improvements to pos-cli site copy are being developed to simplify the migration of constants and background jobs.
These updates support the same broader goal as the AI tooling: reducing repetitive development and infrastructure work so teams can focus more of their effort on the application itself.
Another infrastructure update focused on read replicas for Dedicated Private Stacks.
Developers will be able to route selected GraphQL queries to read replicas instead of sending every database operation to the primary read/write cluster.
This is particularly relevant for read-heavy workloads where some queries, such as searches, do not require a newly written record to appear immediately. Developers can opt individual queries into replica usage, while operations requiring strict consistency can continue using the primary database. If a read replica is not available, the query falls back to its normal behavior.
This gives teams another way to scale database workloads incrementally without scaling the primary database for every increase in read traffic.
Taken individually, the Town Hall demonstrations covered very different territory. Together, they showed AI becoming part of the platformOS ecosystem at three distinct levels.
At the application level, MCP can give AI access to defined actions while keeping security: roles, permissions, and application-specific guardrails in place.
At the product level, Course Creator demonstrated how AI can work inside a domain-specific application, combining natural-language interaction with traditional controls and the context of the workflow itself.
And at the development level, platformOS is evolving its CLI, Supervisor, debugging, Liquid support, and modules to give AI coding agents better context and more predictable tools.
Across all three levels, the common theme is not removing humans or constraints from the process. It is giving AI better context while retaining control over what it can do.
As these capabilities mature, the result may be more than faster development. As Scott's Course Creator demonstrated, they can also expand the range of specialized software that teams can realistically consider building for themselves and their clients.
Ensure your project’s success with the power of platformOS.
