How CoCast Started
AE CoCast did not begin as a planned product. It began with a failure during a live Apex Engine demonstration at DC Tech. The presentation itself was going well. The room was filled with investors, developers, and peers, while several members of the TGS Tech team were connected remotely from different parts of the country. The third-party presentation software being used for the demonstration had other ideas.
What started as a brief network interruption quickly turned into a cascading failure across the entire session. That moment exposed a problem the team had experienced before, but had never examined quite this closely: most screen-sharing tools were still built around a single-presenter model, temporary control handoffs, and session behavior that could become fragile when multiple people needed to participate at once.
What happened next became the starting point for CoCast.
The Demo
During the session, the presentation tool crashed three separate times. One of those failures followed a network interruption that lasted only about 17 seconds. The interruption itself was brief, but its effects spread across the entire session. Shared displays began resetting, mirroring, and collapsing while remote participants tried to recover their screens and restore the presentation. On the third crash, a reconnect triggered the problem again, creating what appeared to be an endless mirror of collapsing displays while the team hurried to remove the affected third-party panels from their primary screens.
In the middle of the confusion, Sarrene Miller looked at the room and said, “I think I just found another piece of software to build. Any questions?” The comment drew some humor from the situation, and the Apex Engine demonstration continued successfully, but the failure itself stayed with her. What had happened was more than an inconvenient crash. It exposed a weakness in the way the collaboration tool handled state changes and recovery during a live multi-user session.
What Actually Went Wrong?
The next morning, Miller began reviewing the source code to understand exactly what had happened. The problem turned out not to be a single isolated bug. The presentation software had been designed to tear down and rebuild significant parts of the session whenever certain state changes occurred. Under the wrong conditions, a small disruption could therefore propagate across multiple participants and shared displays instead of remaining isolated to the affected connection.
Miller sent portions of the code and her findings to several colleagues for review. They were equally surprised by the implementation, but confirmed what she had found. The failure during the demonstration was not simply bad luck. The architecture itself created the conditions for that kind of cascading behavior. That distinction mattered because a single software defect can often be corrected, while a workflow built around the wrong assumptions usually requires a different design.
By the end of that night, Miller had written an 87-page design proposal outlining another approach. The proposal was not intended to recreate the failed product feature for feature. Instead, it began with a broader question: what should collaborative screen sharing actually do when several people are working together at the same time?
A Different Approach to Collaboration
Traditional screen sharing usually revolves around one active presenter. One person shares a screen, stops, and then another person takes over. If someone else needs to show something important, the group pauses while control changes hands. That model works reasonably well for simple presentations, but it becomes increasingly awkward when several sources of information need to remain visible at the same time.
The original CoCast design challenged that assumption. A participant should not have to interrupt another person simply to share something relevant. A temporary connection problem should not force everyone else to rebuild their workspace. Viewers should not have to lose one important screen in order to see another. Most importantly, collaboration should not be organized around a queue of presenters when the work itself is happening simultaneously.
The design instead centered on persistent, multi-participant sharing. Multiple people should be able to broadcast at the same time, and multiple active views should remain available throughout the session. Each participant should be able to focus on the information that matters to them without forcing everyone else into the same view. Those principles became the foundation of what would eventually become AE CoCast.
From Idea to Validation
Over the following months, Miller began discussing the concept with people outside the immediate development team. She spoke with software developers, educators, support teams, business users, and people working in collaboration technology. The conversations were less about selling a finished product and more about testing whether the underlying idea addressed a real problem.
Different groups immediately saw different applications. Developers saw value in keeping code, logs, running applications, and project information visible together. Educators saw the potential to work with multiple student screens and instructional materials without constantly changing presenters. Business teams saw a way to compare several sources of information at once. Support teams saw a way to observe multiple systems or users without losing context.
Despite the different use cases, the response was remarkably consistent: build it.
That feedback reinforced the idea that the problem was broader than one failed demonstration. The need was not simply for another screen-sharing tool. It was for a collaboration environment that treated simultaneous participation as the normal state rather than an exception.
From Proposal to Product
As CoCast moved from concept into development and testing, some parts of the original proposal changed while others became more important. Real-world use exposed new behaviors, edge cases, and workflow requirements that could not have been fully anticipated on paper. The product continued to evolve, but the central principle remained the same: collaboration should not stop every time another person needs to share something.
AE CoCast is now built around simultaneous sharing and persistent visibility. Multiple participants can share at the same time, active broadcasts can remain visible together, and viewers can decide which information deserves their attention without disrupting the rest of the session. The aim is not simply to make traditional screen sharing faster or more polished. It is to remove the repeated handoffs, interruptions, and loss of context that traditional screen-sharing workflows often create.
Why CoCast Exists
The DC Tech demonstration ultimately succeeded, but the problems encountered that day exposed something the team had not set out to solve. A brief network interruption revealed an architectural weakness. Three crashes exposed a broader workflow limitation. The experience raised a simple question: what should collaborative screen sharing have done instead?
That question became the basis for CoCast.
What began as a frustrating failure during an Apex Engine demonstration became the starting point for a different model of collaboration, one built around multiple active participants, multiple visible screens, and the idea that people should be able to work together without waiting for the next presenter handoff.