Sparkwise Architect

The problem we are solving

Many Sparkwise clients over the years have expressed interested in developing learning experiences for our platform themselves (many client organizations have professional learning designers on staff) but building great learning experiences in a unique digital learning venue like ours requires more than domain/content knowledge and expertise in learning design. Great design in a digital learning environment requires a deep understanding of the capabilities, strengths, and quirks of that environment. To make the most of a technology-mediated venue, you need to really understand the ins and outs of that venue. We have developed an understanding of this over the course of the past five years, but it's too much to ask learning designers outside of our own team to learn this in the same way. In order to enable our clients to build Sparkwise experiences themselves, we need to provide a tool that somehow bridges this platform-specific knowledge gap.

Importantly, professional learning designers weren't the only ones interested in building experiences on our platform. We also heard from leaders who have identified gaps that they'd like to address on their teams and were interested in a tool that could help them accomplish this. We wanted Architect to work for them, too.

The controls needed by these two different user personas would be quite different. They both ultimately have the same goal in mind, but they way that they would want to get their would be quite different. The ways in which they would want to delegate vs collaborate might be different. But for both, the goal is the same: start with the kernel of an idea and develop it into a refined module that's ready to run at scale on the Sparkwise platform.

How we approached it

We had been talking about building a productized authoring tool for creating Sparkwise modules for years, but our make-shift original approach was working well enough that this never quite made it to the top of our priority list. With the arrival of increasingly powerful AI engineering tools last year, we felt that the time was right to tackle this project, and decided this would an AI engineering project from Day 1.

Rather than viewing AI engineering primarily as a way to ship product faster, I had three other goals in mind: (1.) to enable us to deliver on a more ambitious product vision, (2.) to experiment with and land on new engineering practices and processes, and (3.) to find inspiration in agentic tooling for software development that we might adapt for learning experience development.

Looking back today, all three goals have largely been met. The version of the Architect vision that we shipped is unquestionably more ambitious than what we would have delivered without AI. We ended up developing a very different product architecture and supporting tooling. And the shape of the product that we ended up shipping was influenced by the best parts of the new class of agentic tools that we used to build it.

Design principles

Before writing any code, we drafted a set of design principles for the project. Looking back, a good number of these held up. Here they are as I wrote them down:

• AI will improve - AI will continue getting more capable over time, so we want to stay flexible.
• AI should not be a requirement - the tool should be fully functional without any AI enhancement.
• AI will make mistakes - the user should always be able to modify or replace AI-generated work.
• AI can assess - aside from generating content, AI can evaluate content quality and fitness.
• Attribution - we should be able to tell what work was done by which author.
• Plans can change - authoring is non-linear, and that shouldn't mean starting over.
• One tool to draft+ship - a single tool covering thinking and designing through polishing and shipping.
• Highlight excellence - show examples of what great looks like.
• Challenges will vary - different authors find different parts of the authoring process hard.
• Version everything - versioning and reverting need to be primitives.
• Team effort - creating and reviewing are collaborative, including asynchronously.

How Architect works

I'll share a short version of the explanation here, one piece at a time. Each of these has a longer story behind it, and I'll be writing those up separately.

• A structured workflow, not a chat box

  A module develops through five design phases, each one more detailed than the last. Each of these phases is made up of steps, and every step is its own small workspace featuring instructions, descriptions of "what good looks like" (formatted both for people and for agents), and a set of rubric-based evaluations for assessing the quality of that step.

• Design expertise encoded as files

  Working with Sparkwise's learning designers, I encoded the method as plain markdown files following the open Agent Skills format. Per-step skill files describe what good looks like, with criteria and worked examples. Operation skills are procedures the AI carries out. Every AI feature in the product reads the same files, so improving one improves all of them.

• Tests that suggest a fix

  Every step carries checks: some scored by AI against a rubric, some deterministic and calculated, and some as a manual sign-off. When a AI-based rubric check fails, its feedback goes back in a bounded loop, so the rubric both grades the work and says what to do about it.

• As much AI as you want

  Architect is fully functional with the AI switched off, and that isn't a crippled trial mode. The level of involvement is chosen step by step rather than once for the whole tool.

• Multiplayer, with both people and AI agents

  Modules are built collaboratively in real time, with asynchronous reviewers and time-boxed external access. The assistant, Archie, works in that same fabric rather than in a chat window off to the side. Everything Archie writes streams into a shared activity feed labelled with which person delegated it, and every change is recorded with its before-state so reverting can be a one-click action.

• Tools the agent writes for itself

  Archie works from a deliberately small set of tools, because every tool added costs the model accuracy in choosing among them. For everything else it composes code on the fly (in a sandbox), which collapses what would have been many round trips into one.

More about Sparkwise.