Misa

When our team arrived, the company already had many developers using ChatGPT. Most used it as a conversational search tool: ask, receive a suggestion, and copy it into the work. The context stayed in private chats, so the next person had to explain the same problem again.

The implementation lead saw interest in AI but no shared process connecting it with company data, tasks, and responsibility for the result. Personal assistance was not yet a common working practice.

We began connecting that work. Engineering needed a shorter path to launch, analytics needed agreed calculation rules, and employees needed help within their daily tools. Misa, an AI assistant in Slack, became an entry point to those sources and actions.

This account reflects the implementation team's experience from June–September 2026. Examples are anonymized.

From private chats to shared work

Before, employees supplied context to private AI chats and manually transferred answers into documents or tasks. The analytics system relied on aging technology and was difficult to explain. A question about a metric often became a search for the person who understood its source.

The team connected a shared layer of data and definitions with working knowledge sources, Jira, and Slack assistance. Misa could take part in a sequence of actions, including producing a file or changing a task on instruction.

The history contains verified task creation, updated analytical files, experiment reviews, leadership materials, and recurring background checks. Users returned to the same documents with new data cuts and corrections, so later requests could continue agreed work.

The intended standard is one metric definition across reports, dashboards, and bot answers, with a clear action owner and a verifiable result. The components are in place for that work, but company-wide adoption is still a next-stage goal.

Engineering: the reported launch timelines

The implementation lead reported a game launch in two months rather than roughly six. A separate statement describes one month instead of six months of work by five developers; whether it refers to the same project is unresolved. These accounts are kept separate, with no combined acceleration or savings figure and no measured attribution to AI alone.

A shorter launch cycle lets the team test the product and decide what to develop next sooner.

That engineering result did not establish shared AI use across the company. Employees still working in personal ChatGPT accounts had no common process to inherit. Bringing assistance into Slack addressed where the wider team already worked.

Analytics: keeping metric definitions consistent

The analytics work addressed how the company defined and compared its metrics.

The previous analytics system was difficult for the team to understand. Connecting a bot without resolving conflicting definitions would have carried those conflicts into its answers.

The team established a shared layer of data and calculation rules. Power BI, other dashboards, and bots should use these agreed definitions. The definition of an active user or conversion must not silently change with the screen on which it is viewed.

This lets people discuss why a metric changed instead of reopening an argument about its formula. If sources disagree, it becomes clear what needs reconciliation.

A weekly-file update exposed the problem in practice. Users found a discrepancy with the current growth dashboard. The team reconciled definitions, changed the calculation basis, checked BI measures, and preserved the familiar Excel template. The file needed comparable numbers as well as a usable format.

The weekly reconciliation links two kinds of continuity. The Excel template preserves where a reader finds a figure; the calculation basis preserves what that figure means. If a definition changes, a period-to-period comparison may need to be recalculated or qualified before the marketer can interpret movement. In this episode, checking BI measures was therefore part of preparing the file. A useful explanation of that correction would identify the affected metric and comparison, so the user knows which earlier conclusion to revisit. The familiar layout helps only when its apparent continuity does not conceal a change in meaning.

Coverage, freshness, and filters still need checking at each connection. Full adoption of the shared metric definitions across Power BI reports, dashboards, and bots remains unverified.

Slack: AI where work already happens

Employees now ask Misa in Slack instead of opening a separate conversation and explaining the company again. They describe the result they need without technical commands. Misa then has to establish the period, retrieve the document, reconcile definitions, and identify the intended audience.

A good request names an action as well as a subject. “Look at the metrics” leaves too many possibilities. “Reconcile these metrics with the report, explain the differences, and attach the corrected file” defines a clear result.

Misa's history includes several forms of this work: analytical exports, calculation checks, task preparation, meeting analysis, documentation, and presentation materials. A person can start with a question, then request a file, give feedback, and receive a new version in the same conversation.

Engineering context and verified handoffs

A developer may need to resolve an unclear requirement or conflicting description before writing code. Misa helps reconstruct that context from tasks, documentation, and implementation details.

Misa is asked to read a task with its documentation, investigate a metric definition, and check whether the implementation matches the description. This is particularly important for a data team: the same name in two reports does not necessarily mean the same formula.

The investigation also has to reach the stakeholder. Its output should say what was checked, where the discrepancy lies, which results it affects, and who should fix it. A SQL query alone leaves those questions unanswered.

On June 16, “Do we already have a task for this?” ended with a verified backlog item. Misa first found related topics, then created the requested task on instruction and read it back. On August 20, she was asked to check delivery of workflow files. The files matched the repository, but loading errors prevented declaring the whole system ready.

The handoff therefore has two checks: whether the implementation matches its description and whether the operation actually works. Misa can gather evidence for both without collapsing them into one readiness claim.

The developer can work from the collected business context, while the stakeholder can see why a filter or duplicate record changes the answer. Neither has to reconstruct the other's part of the question from scratch.

Reading code still does not establish that it works in production. If only the implementation was checked, the conclusion should say so. Creating a task also does not mean the defect is fixed.

Marketing: updating the report people use

For a marketer, the value begins where traffic must be connected with people's behavior. Visits, registrations, and subsequent actions may come from different sources and use different counting rules.

Misa is asked to analyze funnels and channel comparisons, prepare recurring analytical files, and clarify attribution—the rules used to assign a result to an acquisition source. Preserving the link between a figure and its definition matters.

A recurring report update must preserve sheet structure, breakdowns, formulas, number formats, and comparisons with the previous period. Changing the dates is only part of the task. The user needs the familiar file back with current calculations.

In a series of partner reports, the user requested a fresh data cut, another document version, and a more detailed reconciliation. Misa rebuilt the PDFs and checked their completeness. When data lagged, the affected metrics remained marked incomplete rather than being presented as current.

The next request could continue that report in its agreed structure and format. The retained context reduced repeated explanation, while each update still required fresh source checks.

The marketer could then examine where acquisition quality changed, which funnel stage weakened, and whether enough data existed to decide. More registrations alone did not establish a profitable advertising channel.

Product: correcting an experiment comparison

A product manager needs to know what to do with a product change. A table full of metrics is useful only when it is clear who was compared and what the difference means.

Misa receives questions about user behavior, retention, and experiment results. Much of the work happens before the conclusion: checking who actually saw the change, how the groups are defined, and whether the observation period is long enough.

In the July 30 experiment review, the user pointed out that the control group had never seen the new block. Misa revised the analytical document so interaction with the block was assessed for people who could see it, separately from metrics comparable across both groups. An unavailable measure stayed “no data,” not zero conversion.

The experiment correction concerns the population eligible to produce an event. A person who could never see the block cannot demonstrate whether they chose to interact with it. Dividing block interactions by that control population would give a number with the wrong interpretation. The revised document separates a question about engagement among exposed users from a question about differences between experiment groups. The product manager can then examine common outcomes across the groups without implying that a nonexistent control experience performed badly. Exposure-specific engagement can help assess use of the block, but it cannot by itself answer whether the experiment improved a common outcome.

The correction reached the calculation and the revised document, where the expert could check it again. It did not remain an unresolved comment in the conversation.

That distinction changes the product decision. A missing event may be a measurement problem rather than no user action, and an increase in one metric can coexist with deterioration in another.

A useful result for a product manager is a short analysis: what the data supports, what it does not yet establish, and a reasonable next step. Sometimes that step is another measurement check instead of rolling the feature out to everyone.

Sales and commercial teams

Misa prepared a partner-meeting brief and a summary of the active portfolio. For the meeting, she gathered available statuses and questions about upcoming launches. In the portfolio brief, she distinguished independent products from alternative addresses.

Here it is especially important not to confuse a plausible answer with a commercial commitment. A product capability needs confirmation, a figure needs a period and source, and missing information needs to be stated plainly.

Personalized negotiation briefs and draft follow-ups are possible next uses.

A draft for the quarterly investor letter

An executive rarely needs another long task list. They need to understand what changed, where the risk lies, and what decision they need to make.

Misa draws on discussions, reports, and the task tracker to prepare the business picture. She has to distinguish discussion, task creation, implementation, and actual business use: each represents a different stage of progress.

Another benefit is being able to question a management figure. What exactly is counted? For which period? Do the report and documentation use agreed definitions? Is the metric suitable for a decision now?

On August 24, the CEO asked Misa to draft “what went well” and “what did not” for a quarterly investor letter. She used working reports and separated activity from demonstrated economic effects. The draft was prepared; approval and delivery to investors remain unconfirmed. Other executive questions sometimes reached Misa through the team.

The executive could review which reported initiatives belonged in the positive and negative sections, keeping progress visible where their economic effect remained unmeasured.

The executive received a cross-functional draft to challenge and edit, rather than having to assemble each source into the initial account.

The executive retains priorities, acceptable risk, and responsibility for decisions.

Operations, meetings, and hiring

After a working meeting on June 26, Misa prepared a brief on stalled work, tasks to create, and questions for planning. She kept those categories separate, retained uncertainties, and identified next actions. The team could use the brief to prepare its follow-up instead of replaying the recording.

The purpose is to recover agreements. If the meeting only discussed who might own the work, the assistant must not assign someone on its own. If no deadline was mentioned, a polished document must not invent one.

On July 6, a manager was preparing to interview an analyst. Misa developed questions from the team's actual work: report discrepancies, metric definitions, data quality, experiments, and stakeholder communication. She then shortened the list and proposed a practical exercise.

The hiring work ended with interview material; the hiring outcome is unknown. Completion of the actions in the meeting summary also remains unconfirmed.

The Data Times: assembly and editorial review

Some work is difficult to place in one department: turning what the company knows into material people want to read.

Misa's history includes editions of the internal digest The Data Times. They collect working events in a designed publication. The user discusses content, illustrations, and format with the assistant; the result goes through several revisions.

The July 3 Data Times edition passed a technical page check but was still missing required illustrations. The user caught the omission: the publication opened, yet it did not meet the assignment.

The team corrected the material and the checking rules. A later review found that cropping a cover horizontally did not satisfy the request for a genuinely horizontal source image. Misa had to remake the image itself.

The two illustration corrections require different evidence. Missing artwork is a completeness problem: the editor must be able to find an illustration in each place the assignment requires one. The cover problem concerns the underlying asset. A horizontal frame can hide part of a vertical composition while leaving the source image unchanged. Checking only the rendered page would miss that distinction. A repeatable acceptance check for this digest would therefore inspect both the publication and the replacement image. That would carry the editor's actual requirement into the next edition, rather than saving a narrower instruction to adjust the page crop.

The person sets the editorial standard and accepts the result; Misa assembles and revises the publication in the same conversation. The exchange can carry a piece through several versions, but it does not replace editorial judgment.

Tools between the request and the result

A Slack request can draw on several tools. Their roles explain the workflow:

• Correspondence and meeting materials help reconstruct what was discussed and agreed.
• Jira holds tasks, statuses, and relationships between work items.
• Confluence and the knowledge base help find definitions, decisions, and instructions.
• Analytics systems provide events and metrics for calculations.
• Repositories help check how a rule is implemented in code.
• Documents, spreadsheets, and visual tools turn work into a result that can be handed on.

A tool named in the design, a configured connection, and a completed operation are different states. Access can change, sources can become unavailable, and an old route can be retired. The result needs evidence of the operation actually performed.

The right response to an unavailable source is to state the limitation. Reconstructing a number “from memory” and calling it a fresh calculation is not acceptable.

Jira: turning discussion into clear work

Previously, even a useful answer in a personal AI chat had to be turned into a task manually. Misa's work includes confirmed sequences of creating tasks, changing assignments, and retaining relationships between work items on a person's instructions.

The user can narrow a task, link it to an initiative, or pass it to another contributor. Misa must preserve that instruction and read back the change in Jira. The useful outcome is the requested work item and its relationships, not a larger card count.

Scheduled Jira support included change monitoring, mention reminders, and checks on response and feedback deadlines. Notification delivery and service-level performance still needed monitoring.

Task authorship also needed correction. In one episode, integration actions were attributed to a person. After feedback, the team checked creation from a dedicated service account on July 13 so the automatic action had a clear author, requester, and assignee.

Those identities answer different questions when someone later opens the task. The service account identifies the integration that performed the operation. The requester explains whose instruction it carried out. The assignee identifies the person expected to work on the item. Combining those roles under a person's account can make an automated change look like that person's own decision. Read-back also gives the user a chance to inspect the persisted task after a change of scope or assignment. The relevant evidence is what Jira retained, including the intended relationship to other work, rather than the wording of Misa's confirmation in Slack.

Background work and delivery checks

Scheduled automations covered several jobs.

• Working memory. Gather changes from working sources, meeting materials, and Jira; update the searchable knowledge base.
• Process support. Watch tasks and remind people about response deadlines.
• Operational visibility. A recurring data-processing volume card to track load.
• Assistant maintenance. Update local repositories, check the quality of saved context, and maintain repeatable instructions.

Some of these operations use ordinary scripts. A language model is not needed to check whether new data has arrived. AI is used where meaningful selection or interpretation is required.

Some reporting flows were paused. Some maintenance checks found problems despite completing without a technical error. Background work still needed supervision.

On-demand and scheduled work are different modes. “This report can be updated regularly” does not mean a daily distribution has been created.

A schedule needs its own collection scope, timing, destination, authorization period, and failure handling. Analytics retries consume resources too, so an on-demand report cannot silently become a recurring job.

Some background work should update context without posting to chat; other jobs should report only a change. Sending a message for every technical run would make useful alerts harder to notice.

The business needs to see the state of a specific process: whether it is enabled or paused, whether a run succeeded, whether the data is current, and whether the recipient received the result. A schedule entry alone does not answer these questions.

How Misa makes mistakes—and what to do about them

Assistant errors are not limited to invented facts. It may understand the subject but fail to perform the required action. It may prepare a file in the wrong format, ask again for permission already granted, or say “done” too early.

In working use, these behaviors have a specific cost: the user spends attention managing the assistant and repeating earlier explanations. Ignoring that cost overstates efficiency.

The illustration failure showed that a technical check can miss part of an assignment. The recurring reports exposed a different problem: authorization, technical access, the permitted retrieval method, and file readiness require separate checks. Confusing them makes the user repeat approvals without resolving the actual blocker.

Corrections need to become working instructions that a later session receives and applies. Saying a rule has been remembered is not evidence that the next request will follow it.

How to tell whether the assistant pays off

Misa's overall return on investment has not been measured.

Based on team estimates, a recurring report update in its existing format takes around 30 minutes of the analyst's time with Misa, including the checks, against roughly 2.5 hours of manual collection, reconciliation, and rebuilding: around 5× faster. The minutes are estimates for that one repeat task, not measured durations.

Value is better assessed through repeatable tasks. Choose a specific process, such as updating a report or preparing meeting notes, and compare its full cost with and without the assistant.

Measure time to an accepted result, returns for revision, human correction time, and execution cost. If the assistant writes a first version quickly but the requester spends a long time explaining what was lost, that is part of the result too.

Repeat use also gives qualitative signals: the same format no longer needs explaining, reports preserve definitions, conclusions lead back to sources, and meeting summaries retain open questions. These help explain why employees return to Misa, but are not a monetary ROI calculation.

The next stage: making good results repeatable

The next stage is to extend shared metric definitions to the remaining consumers, retire obsolete routes, verify background-job outcomes, and measure human correction time. Each change addresses a problem already visible in the working history.

For a new team, the best first request is a familiar task with a verifiable result. Choose a report, document, or analysis already produced regularly, rather than “help our department work more efficiently.”

For example:

Reconcile the metrics in the attached report with the agreed definitions. Show discrepancies and limitations. Return the corrected file in the same structure; if recalculation was not completed, say so explicitly.

Or:

Use the meeting materials to prepare a short summary: what was decided, which actions were agreed, and what remains open. Do not invent owners or deadlines. Do not create tasks yet.

Example requests.

It is easier to begin with reversible actions. Checking a document is simpler than authorizing independent customer messages or production changes. Add automation once the sources, rules, format, and verification method are clear.

The next similar request should need fewer explanations and return the agreed result. That is the test of whether Misa’s working instructions help the team.