How to use Luciq with AI: which path fits your team

This guide covers the six ways to use AI with Luciq: Luciq Agent, the MCP server, Agent Skills, one-click handoff, the CLI, and Claude Routines, and when to use each.

A model working from a stack trace alone is guessing. A model working from what happened on the device is debugging.

Every team has access to the same models now. They can read your code, write a fix, and open a pull request. What they can't see is what your users went through: the screens before the crash, the logs your code wrote on the way there, the state of the device, and what the user said about it afterwards. That's the difference between a plausible fix and the right one.

Most monitoring tools now offer several ways to put AI on their data: their own agent, an MCP server, a CLI, and handoffs to your coding agent. The question we hear most from teams is which one to use, and when. Here's how we think about it, and how each path works with Luciq.

1. Context decides the fix, not the model. A stack trace tells you where the app died. It doesn't tell you how it got there. Give your agent the path into the crash: the most common steps before it, the logs your code wrote, and how it spreads across devices and versions. Some problems never throw an error at all. A button stops responding. A screen flickers. A user taps the same spot again and again, then gives up. None of that is in a log file. It's in the session, and an agent can only reason about it if it can see it.

2. Put the review at the pull request. Let the agent investigate, reproduce, and write the fix. Put the person where the decision is: the pull request, before anything ships.

3. Pull data with scripts, reason with models. Running thousands of records through a model costs tokens and fills its context with noise. Pull volume with a script, then hand the agent the small slice that needs thinking.

4. Bring the context to the agent your team already uses. If your team doesn't have a coding agent yet, start with what's built into Luciq. If your developers already work with Claude Code, Copilot, or Cursor, bring Luciq's context to the agent they trust. The data is the same either way, so you can move between paths as your setup changes.

Luciq Agent is available in the dashboard and in Slack. It works across everything Luciq collects: crashes, app hangs, performance, bug reports, session replays, app store reviews, surveys, alerts, and the issues Luciq detects in sessions, like broken functionality and visual glitches. It connects data that sits on different pages, so "Which crashes are showing up in our 1-star reviews?" is one question. It can also act, like updating a bug or building a funnel, and it asks for your approval before every change.

Use it when someone needs an answer across products: a PM sizing up a release, an EM writing the weekly update, a QA lead checking which flows produce the most bug reports.

Other examples:

It can act for you, with your approval:

Skip it when you need thousands of records or a job that runs on a schedule. That's work for the CLI.

Luciq Agent in the dashboard, comparing crash-free rate across the last three versions.

The same question, asked to Luciq Agent in Slack.

Start here: Luciq Agent docs

Open any crash, choose Investigate, then Luciq Agent. It finds the root cause with its evidence, the steps that reproduce it, and the patterns across occurrences, like devices, OS versions, and app state. It then suggests a fix in code. To track the work, it can forward the crash to your issue tracker and/or GitHub.

Use it when you want a diagnosis and a proposed fix without setting up an agent.

Skip it when your team already has a coding agent that knows the repository, its conventions, and its tests. Bring Luciq's context to that agent instead.

Investigate on a crash: hand it to Luciq Agent, Claude, or Cursor.

Luciq Agent's root cause for a crash: the exception, where it happened, its impact, and a suggested fix.

Start here: open a crash, choose "Investigate", then "Luciq Agent".

Many developers already trust an agent in their editor with their code. They don't want a second one. They want theirs to know what Luciq knows.

MCP (Model Context Protocol) is the standard way for an agent to call outside tools. The Luciq MCP server lets Claude Code, Copilot, Cursor, and other clients read your crashes, performance, bugs, sessions, and reviews. It can also act, like setting a crash's priority or filing it in your issue tracker. It signs in with your Luciq account and permissions, and it's included in every plan.

Some things to ask your agent:

Use it when the question is open-ended. "What started failing after yesterday's release?" takes a few follow-up questions, and agents handle follow-ups well.

Skip it when you need the same answer in the same shape every time. That's the CLI.

Start here: claude mcp add --transport http luciq https://api.luciq.ai/api/mcp, or setup for other IDEs.

A tool tells an agent what data exists. A skill tells it how to investigate. Without a method, an agent makes a few calls and guesses. Luciq's Agent Skills are playbooks for mobile problems, such as debugging a crash against your local code or writing a health report for your team. Your agent gets them through the MCP server, and they stay current.

A skill starts when you ask something like:

Use it when you want your agent to investigate the way a mobile engineer would, not only fetch data.

Skip it when you're writing your own prompts and only need the data. The MCP server is enough.

Start here: Agent Skills docs

When you find a problem on the dashboard, you shouldn't have to copy links into your agent. From a bug report, a crash, or a slow network call, screen, or flow, send it to Claude or Cursor with the context already loaded. From a crash, you can also copy a summary across all its occurrences for any agent. Your agent debugs and writes the fix in your codebase.

Use it when you spot a problem on the dashboard and want your agent to pick it up from there.

Skip it when the work should start without anyone looking. That's Claude Routines.

Open in on a bug report sends it to Claude or Cursor with the context already loaded.

Start here: "Open in" on a bug report, "Investigate" on a crash or performance metric, or "Copy for AI agent" in a crash's Debugging tab.

The CLI runs the same tools as the MCP server, from a terminal or a script. It returns JSON and fails with an exit code, so a build can pass or fail on it. No model is involved, so a bulk pull costs no tokens.

Our rule of thumb: the MCP is for conversation, the CLI is for automation. Use the CLI to upload symbols on every release, pull the week's top crashes into an internal dashboard, or stop a release when crash-free sessions drop below your bar.

Start here: brew install luciqai/tap/luciq-cli, then luciq login. CLI docs

A Claude routine is an agent you set up once in Claude, with instructions, a repository, and the tools it may use. In Luciq, you connect the routine and choose what starts it: every new bug or crash, a rule you set on bugs, crashes, or performance, or a one-off forward. Luciq sends the event to the routine, and the routine does what you told it: investigate, open a pull request, post in Slack. Bug reports carry text your users wrote, so give the routine only the tools it needs and keep a person on the merge.

An example instruction: "When a new bug comes in, find the cause in the repository, open a draft pull request, and post the link in #mobile-oncall."

Use it when you know what should happen when a specific bug, crash, or alert comes in, and you want the work to start before anyone opens it.

The Claude Routine integration in Luciq, set to forward every new bug and crash.

A Claude routine run started by a new Luciq bug. It found the cause, fixed it, and opened a pull request.

Start here: Claude Routine integration docs

On Monday, the PM asks Luciq Agent in Slack to compare crash-free rate across the last three versions. On Tuesday, the release build uploads its symbols with the CLI, and a CI step holds the rollout until crash-free sessions clear the team's bar. On Wednesday at 3 a.m., a crash spike alert fires a Claude routine. By the time the on-call engineer opens the alert, the findings and a proposed fix are waiting for review. On Thursday, a developer sees a new bug report on the dashboard, opens it in Cursor, and fixes it in the same session.

No path replaces another. Each one takes the part of the week it fits.