Artemis
Design engineering the discovery and help experience of an AI platform
Overview
Kore.ai's Artemis is the latest edition of its Agent Platform, an enterprise platform for building, testing, and deploying AI agents. Built with AI from the ground up, it is designed to become the foundation layer that all of Kore.ai's offerings live in.
I work on Artemis as one of the first designers in the org's design engineering function, where designers ship their design decisions directly in the product's code. This case study covers my first major initiative on the platform: its platform discovery and help centre experience, both designed, built, and shipped by me on the live product.
Background
At the beginning of 2026, the senior leadership set a new direction for the company: to rebuild the Agent Platform from the ground up, leveraging AI at every step of the process, as a new platform called Artemis. More than a successor, it is the layer that all of Kore.ai's existing offerings will plug into, including the previous Agent Platform I had worked extensively on and the XO suite of products (Contact Center AI, Automation AI, Search AI, and Quality AI).
This direction changed how design works as much as what was built. All departments were supposed to use agentic coding tools. The work was expected to be faster and better. Manual Figma files and developer handoffs no longer fit the new workflow, and gave way to design engineering. Iterations now live in the codebase rather than in design files.
I was among the first designers to move into the function, which meant learning the codebase, the tooling, and the release process on my own, while carrying a deliberately open brief: improve the overall experience of the product through clean-up jobs, initiatives, and redesigns. Artemis was moving fast and already supported a wide set of features when I jumped in; my job was to find where design attention would matter most, and then ship it myself.
Problem
I went through the product hunting for rough edges and opportunities where design could pull its weight, and shortlisted a few areas from the many. The one this case study follows came from a simple question: what does a user completely oblivious to AI agents and Artemis see the first time they land in the product?
The answer was not a lot. There was no first-run experience. To understand what that felt like, I created a fresh workspace and walked the product as a stranger, and kept getting lost, from setting up the workspace to building an agent to testing it. The friction was heaviest right at the start, where I struggled to understand where and how to get going. I had designed for this exact domain on the previous iteration of Agent Platform and still got lost. If I was lost, a new user stood no chance.
The first screen of a brand new workspace from a previous build.
I wrote every stumble down, and the list kept circling the same gaps:
- A new workspace lands you on an empty state with no explanation of what Artemis is or how to get started
- Three big names - Artemis, Arch, and ABL - that you see everywhere in the platform and are never explained
- No mental model of the platform hierarchy: what is a project, what is an agent, and what kinds of features the platform holds
- New capabilities the platform is proud of, which the user has no way of knowing about
Design
The first initiative that came out of this is a simple first-run experience. I built the layout gradually as working UI instead of mockups, reviewed iterations on live builds, and shipped through the same pull requests as any engineer.
Part I: Get Started
The first-run experience receives a user who has just created their workspace. Rather than a separate tour or a modal, I built it into the empty state of the projects page itself since it's the first screen every new workspace lands on. It does its explaining exactly where the void used to be.
The screen is two halves. The left half does the job of educating users about the platform in three slides: a product intro video, then the three names - Artemis, Arch, and ABL - that are everywhere on the platform and explained nowhere, then how work is organized from the workspace down through projects to the agents, tools, and knowledge inside them.
The right half is a rail of actions, and its design is mostly a ranking exercise. We realised early that a new user given eight equal options will pick none of them, so the rail forces a visual hierarchy instead. Build with Arch is the primary intended journey. We want the user to get the hang of the product quickly, and building with Arch is a natural language experience designed to be the easiest and fastest route from an empty workspace to something you can test.
Alternative ways like creating a blank project or starting from a template sit beneath it, quieter. Then comes connecting the Artemis MCP server, and inviting the team. This also gives one of our newest capabilities, the MCP server, its first UI placement in the platform. Docs, Academy, and Support close the rail as external links.
Building in code surfaced edges that never show up in a happy-path mockup. There are cases where the user might land in a shared workspace without permissions to create a project. On accounts like these, restricted actions render disabled with an explanation, instead of letting someone click through to a permission error.
Part II: Help Centre
The Get Started screen serves a brand new workspace, and by design it retires once projects exist. But needing help doesn't retire with it. Users deeper into the product had nowhere to turn. The second initiative was a Help Centre - a panel reachable from anywhere in the product, for whenever a user wants detailed guidance about the platform and its features.
Since the Help Centre follows users who are already building, it had to offer more than the Get Started page did. The Overview tab on the Help Centre opens with a What's New banner that links to the platform release notes, then the essential items for getting started. This is also where we gave the CLI and the Artemis MCP server a permanent in-product home. Below them sits the same grounding the carousel gives new users on what Artemis, Arch, and ABL are.
The Videos tab took coordination beyond design. From the learnings of building a similar feature in the previous iteration of the platform, we wanted the video catalog hosted externally. That way, we curate videos on our own schedule, and the product never needs a release when we modify the catalog. I worked with the marketing team to host it on a page on the kore.ai domain, with a CMS accessible to the product team. Challenges emerged along the way, including making the externally hosted library theme-aware, so that it loads in dark mode when the user has the product set to dark theme.
Docs got the same curation the rest of the surface did: three essentials promoted at the top, then a few documentation pages grouped by the platform lifecycle - Build, Scale, Optimize. Each card opens its detailed page externally. Academy and Support stay in the rail as direct external links.
Outcome
Both initiatives shipped to production on the platform's regular release train and are live today. Every new workspace opens on a guided first step instead of a blank page, and help is one click away from anywhere in the product. With instrumentation on the Help Centre's entry points recording which one people actually reach for, the next iteration starts from evidence.
The merged PRs behind these releases.
Some of what shipped serves the platform beyond onboarding. The CLI and the MCP server have their first placements inside the product. Marketing runs the video catalog without waiting on releases. And for the design org, these releases did a quieter job too, as early proof that a designer can carry an initiative from noticing a problem to shipping the fix, entirely within the new function.
Reflection
Designing in the codebase
Being among the first designers in the function meant no playbook existed for any of this - how to structure my PRs, what reviewers expect, when to ship. I wrote mine as I went. But the climb pays for itself, because designing inside the codebase gives you something Figma can't. A Figma file is a promise about the product. Code is the product.
That ownership extends to details no mockup carries. I created design system components and tokens along the way, introduced micro-interactions nobody had paid attention to, and kept layouts pixel-perfect and brand-aware in a way no AI slop can produce. Constraints I would never have met in a mockup, like permission models, turned out to be design inputs rather than blockers. And the feedback loop collapsed: an idea in the morning could be on a live build by evening, reviewed as the thing itself rather than a picture of it. The best thing about design engineering is noticing the smallest things, and being able to act on them.
Get lost on purpose
The whole initiative began because I let myself be a beginner in a product I technically knew. Fluency is the enemy of onboarding design: everyone building Artemis was too close to it to see that its first five minutes explained nothing. Walking in as a stranger and writing down every stumble before the confusion faded produced the problem list everything above was built from. Confusion is data, and it expires fast.