Instana AI Strategy

The starting move was naming what AI actually was inside the product. Five capability types, each playing a different role.

Naming the types gave every team a vocabulary to locate their work in. The summary button sat in Generative. Smart alerts sat in Predictive. Both were AI in a meaningful sense, and both belonged in the same picture.

The capabilities had to connect, not just coexist. I put the chatbot at the center of the interaction model and made the rest of the product the spokes around it.

The chatbot pointed outward to do work in the product. It navigated the user to relevant views. It built things (dashboards, runbooks, summaries) on demand. It served as the entry point for AI features embedded elsewhere in the UI.

The product pointed back to do work in the chatbot. A probable root cause analysis or an insight on a page could launch a chat thread for deeper investigation. AI outputs landed in the chat panel for follow-up.

The chatbot acted as connective tissue between AI capabilities and the rest of the product.

Knowing what AI is and how it connects was not enough. The framework also had to specify where AI shows up in the interface and what kind of behavior lives at each surface. Four patterns covered the territory.

Each pattern had a different design challenge. Knowing the framework allowed new features to be built systematically and efficiently within it.

I worked with the architects to understand the systems beneath the framework. My role wasn't to design the technical architecture — it was to communicate the mission to engineering, weigh tradeoffs with the architects building it, and translate the resulting limits and opportunities back to the design teams.

The Summarize button itself shipped in Q1 2025. This was the original feature behind the strategy, and it landed in the framework as a Contextual Launch: AI attached to a specific object in the product, surfaced at the moment of need, generating output that lives in context.

Treating the button as one instance of a pattern, instead of a one-off feature, meant designing it to coexist gracefully with everything else AI was going to do across the product.

When something breaks in production, an incident gets shared many times to many different people. Executives need to know impact and duration. On-call SREs need probable cause and potential fixes. Downstream engineers need the full technical picture.

I designed a sharing flow where the user picks who the share is for, and the AI generates a summary tailored to that audience:

A user asks the chatbot something specific: “Show me latency for our checkout service over the last week.” The chatbot’s answer is the dashboard itself. It builds it on the fly, then navigates the user to it. The user lands on a new persistent dashboard view, ready to be saved, shared, or extended.

This single flow exercises three patterns at once. It starts in Self-Contained Chat (the user asks). It produces an Artifact (the dashboard). It ends in Chat-Driven Navigation (the user lands on the new view). The chatbot moves from answerer to builder to guide in one user action.

When an incident hits, the response often involves running remediation steps that may or may not have been documented before. I designed a flow where the chatbot, anchored to the incident at hand, generates a candidate runbook, pulling from documentation, prior incident histories, and the engineer’s intent in the moment.

The runbook lands in the product as an artifact. The user can run it as-is, or click into it to open a chat thread for refinement: “Make this safer,” “Skip step three,” “Add a rollback at the end.” The chat takes the artifact, modifies it, and returns it to the product.

This is Artifact Creation feeding into the bidirectional product-to-chat loop from the interaction model, and pointing toward Agentic AI, where the next step is the chatbot offering to execute the runbook itself.