Ryan Brown

2017–2019 · Infosys

Learned to investigate before prescribing.

I learned to trace behavior, test assumptions, document what I could prove, and separate symptoms from the source of a problem.

2019–2020 · PowerObjects

Moved closer to the people using the system.

Working directly with users, managers, vendors, and technical teams changed what I considered a good solution. The design had to fit the people and the environment around it.

2020–2022 · Procentrix

Started owning the space between the request and the solution.

I spent more time translating needs, surfacing delivery risk, challenging requirements, and helping people make decisions before engineering moved too far.

2022–Present · Cyclotron

The system became bigger than the software.

Architecture, AI, governance, delivery, adoption, and organizational change became one connected problem. My work now sits across those boundaries.

Business

Choose what is worth solving.

I bring leadership and consulting into the same conversation: clarify priorities, understand the work, and make the tradeoffs explicit. Governance gives the decision practical boundaries.

• Clarify the priority
• Understand the constraints
• Agree on the next decision

Engineering

Turn the decision into a working system.

I design the architecture, prototype with AI, and test assumptions early. I stay close to delivery so the system can adapt when the real environment challenges the plan.

• Prototype the uncertain parts
• Validate the architecture
• Build a foundation others can extend

People

Make the change something teams can own.

Enablement and adoption are part of delivery. I help teams build the knowledge, shared practices, and feedback habits to operate and evolve what we built.

• Share the operating knowledge
• Build adoption into delivery
• Keep feedback connected to the system

Forge: Asset Creation & Management

Forge brings asset creation and management into one workflow. It supports procedural tools for creating geometry, materials, textures, sounds, and effects, while giving individuals and teams a central repository for organizing, revising, and reusing their work.

Assets can be created in the tools you already use, including AI assistants, without tying the library to a particular editor or chat platform. The CLI lets teams sync and manage assets locally as part of a repeatable workflow, so useful work remains traceable and maintained rather than becoming a collection of throwaway outputs.

The same repository can support asset management on its own, with assets made available or shared when needed. The aim is to make assets easy to integrate into Three.js and other runtimes or cloud platforms, so creators can build and distribute their work without reorganizing it around every destination. Basic scene composition in the UI is planned.

Questions I’m exploring

• How can assets created across different tools become a coherent, reusable library?
• How can procedural creation preserve the recipes and context needed to revise an asset?
• What makes local asset sync and revision management practical for individuals and teams?
• How can the same asset library support sharing and integration across runtimes and cloud platforms?

Muse: Music Learning & Composition

Muse is an experiment in making music theory easier to learn through practice. Instead of starting with a chat interface, it starts with a MIDI keyboard and sheet music.

The idea is to connect what you're playing to what you're learning. You can work through guided exercises, compose music, and receive feedback based on your actual playing. AI provides explanations, suggests exercises, and helps identify areas to practice, but the instrument and music remain the focus. I’m also exploring how AI can understand the mathematical nuances of music and use that understanding to create targeted learning activities.

Questions I’m exploring

• How can AI understand the mathematical nuances of music and create targeted learning activities?
• Can we identify gaps in someone's understanding from how they play?
• How can music theory be introduced naturally through practice?
• What does useful, personalized feedback look like without turning everything into a conversation?
• Can the same environment support both structured learning and open-ended composition?

Defender: System Diagnostics & Security

Defender makes operating system information available to AI assistants through a read-only MCP server.

It exposes things like running services, resource usage, network connections, and firewall information on Windows and Linux. The idea is simple: an assistant can be much more useful when it can inspect what's happening on a machine instead of asking someone to manually collect logs or run commands.

It's not intended to replace security software. I'm interested in whether AI can help people investigate problems, connect observations, and better understand their own systems.

Questions I’m exploring

• Which system observations are actually useful for AI-assisted investigation?
• Can an assistant connect network, process, and performance data to identify likely causes of a problem?
• How much diagnostic capability can be provided safely through read-only access?
• Where does AI help, and where are traditional monitoring tools more reliable?

Beacon: Local MCP Gateway

Beacon addresses a practical limitation with MCP: many useful tools run locally, but sharing them across users or applications introduces questions around access, security, and ownership.

It's a gateway for connecting enrolled devices and exposing their local MCP capabilities remotely. The emphasis is on enterprise use, where an organization needs to control who can discover and invoke tools, which devices they can reach, and when an owner or administrator needs to approve access.

Rather than moving every local tool into the cloud, Beacon provides a way to govern access to tools where they already run.

Questions I’m exploring

• How should organizations manage access to MCP tools running on employee or managed devices?
• How do you preserve device ownership while allowing others to use its capabilities?
• What should require approval, and what can be handled through existing permissions?
• How do you make remote MCP access auditable and revocable?

Current: Independent Agent Collaboration

Current came out of an interest in what happens when people have multiple AI agents running independently, sometimes across different projects or coding tools.

Those agents might be working on related problems, but they have no way of knowing that. Current uses hooks in their existing harnesses to observe activity and look for meaningful overlap. It also gathers token usage and attribution information to help understand where agent activity and resource usage come from. When collaboration makes sense, agents could exchange context, coordinate work, or access each other's capabilities through the appropriate MCP tools.

Users and supervisors can also introduce context or help coordinate agents. The intention isn't to create another framework that controls every agent, but to let otherwise independent agents collaborate when there's a reason to.

Questions I’m exploring

• How do you determine whether two agents are working on something related?
• What context is worth sharing, and what would just add noise?
• Can agents coordinate without giving up control of their own work?
• When should agents connect automatically, and when should a person make that decision?
• How do you prevent collaboration from becoming another source of context growth and unnecessary tool calls?