Product chat

Product chat is a conversation with an agent about one of your products. Ask it what the specification decided, how the code actually handles something, why last night’s build failed, what is deployed where, or what to build next. It reads before it answers, and the answer says what it read.

What it says about your product comes from your product, not from general knowledge. Asked what to build next, it may add a few general ideas after the ones your product suggests, labeled as general. Where it finds nothing, it says so rather than offering a plausible guess, because a confident wrong answer about your own product costs more than an honest gap.

Where it is

The chat opens as a panel over whatever page you are on, from Agent at the bottom of the window or with Cmd/Ctrl+J. It also has a page of its own, Agent in the sidebar or G then J, for when you want the room. They are the same chat in two sizes: a conversation started in the panel continues on the page, and everything works the same in both. You can keep several chats open at once.

A chat is about one product. A new chat takes the product of the page you are on. Opened somewhere that is not about one product, such as your inbox, it takes the product you last chatted about, or asks you to choose one. Either way you can pick another before you send the first message. From then on it belongs to that product.

While you are on one of the product’s initiatives, the chat is told which one, so “this” means the initiative on your screen. It follows you: on another initiative’s page it is that one, and on a page with no initiative it is none.

What it reads

It reads as you. Every read goes through the same permission checks you would, at the moment of the read. It cannot open a document, a run or a file you could not open yourself, and a change to your role applies from its next read, not its next session.

Within that, it has five kinds of source:

• The product’s published documents, on both timelines: what you intend and what the code actually is.
• Knowledge: the reference material available to the product.
• The product’s current state: initiatives, runs and why they failed, maintenance findings, policy divergences, deployments, environment health, monitoring and delivery metrics.
• The code in the product’s linked repository, read at a pinned commit.
• Public sources outside the product: the cloud providers’ documentation, the source and history of public libraries, and a web page whose address it already has.

It picks the source the question is about. What was intended comes from the plan documents. What the code does comes from the reality documents, or from the code itself when they are silent or old. What is true right now, what is failing, open or deployed, comes from the product’s state, never from a document written last month. For a bug or an outage it starts from the state, because the code says what could happen and the state says what did.

It reaches outside your product only when your product’s own material cannot answer, and the answer says when it did. It does not search the web.

A product with nothing published yet can still be asked about. The chat reads the linked repository or the knowledge instead, and says that the answer comes from there.

The chat follows your organization’s policies and the instructions at every level, the same standing context every agent works from.

Sources

An answer that rests on a document cites it: a small number after the claim, linking to the document, its version and its section, and marked when the document is a reality one.

Each citation carries a quote, and Taiga checks that quote against the document the agent actually read before showing it as a source. A citation that does not check out is not shown as one. The answer says instead that the statement has no verified source, and why: the quote is not in the document, the document was never read, or no quote was given. Treat such a statement the way you would an unsourced claim from a colleague: possibly right, and yours to check.

Facts from the product’s state or from the code are not numbered. The answer names them in the text instead: the finding or the run by name, or the file and line with the commit it was read at.

None of this replaces reading the source when it matters. Read the work, not the account of it applies here as much as anywhere: a citation is there so that checking takes one click.

How a turn goes

Before it reads, the agent says in a line what it is checking. The answer then arrives as it is written, and you can stop it partway.

The answer is written on Taiga’s side, not in your browser. Close the panel, move to another page or reload, and it carries on; the answer is there when you come back to the chat.

A question that needs a lot of the repository pauses after a set amount of reading and searching there, answers from what it has, and says how far it got. Continue picks up from there. The pause is deliberate: every extra file is time you wait, and a question that needs fifty files usually needs to be asked more narrowly.

If a turn fails, you can retry it. As with any agent, a retry is a fresh attempt, not a replay.

Your organization has a daily budget for product chat, shared by everyone in it. When it is spent, the chat says so and how long until it resets, at midnight UTC.

What it can make for you

The chat changes nothing by itself. It does not edit documents, initiatives or settings, and it does not start runs.

What it can do, when you ask, is put something in front of you to act on:

• A brief for new work, which you add to the backlog, where an agent turns it into initiatives.
• A rewritten initiative description, shown against the current one, which you apply with a button.
• A document to download, such as a stakeholder brief or a handover.

It makes them only when asked, never on its own, so a chat where you were thinking aloud does not end with something you did not want.

It asks before it makes. First it reads what your product already says, then it works out what is still missing. It asks only about a gap whose answer would change what it makes: one question at a time, each with the answer it would assume and tied to what it read, and at most three in all. For example: “The specification has self-service sign-up but nothing after it. Whose onboarding should improve, new customers or new staff? I’d guess new customers.” Anything still unknown after that is written into the result as an open question or an assumption, never filled in.

If you already know what you want, say so. “Just write it” skips the questions, and the assumptions it had to make are listed at the top of the result, where you will see them first.

Drafting a brief

Ask for it: “make this an initiative”, “add this to the backlog”, or “I want to add an initiative, help me shape it”. Before it drafts, it needs three things: the problem and who has it, the outcome that would show it worked, and what is in and out of scope.

The draft is a card

The draft arrives as a card with a title and the whole brief, which you can read as it renders or as Markdown, and copy as Markdown. A brief is not an initiative yet. Nothing is created until you add it to the backlog, and what it becomes there, one initiative or several, is decided then. The card is the outline: there is no separate plan to agree first, because changing the card is as cheap as changing an outline.

The brief keeps apart what you said and what the agent is suggesting. What you asked for is written in your terms, under its own heading. The agent’s own ideas sit under a separate heading and are worded as suggestions, because a sensible detail nobody raised, written into the scope, reads later as a decision you made. Anything the conversation did not cover is written as not discussed. Read the suggestions as the agent’s: to make one part of the work, ask for it to be moved into the scope.

To change the draft, say what to change: “make it SAML instead”, “drop the logging part”. A new card replaces the old one, and the old card says it was replaced and can no longer be added. A second, different piece of work in the same chat is a brief of its own, and both can be added.

Adding it to the backlog

Adding the card hands the brief to the same agent that handles a request on the Initiatives page. That agent reads the product’s documents and its linked repository, expands the brief, and decides whether it is one initiative or an ordered set of them with their dependencies linked. It keeps the brief’s parts for what they are: your scope becomes the initiative’s scope, the agent’s suggestions do not (at most they are mentioned in the initiative as suggested, not decided), and what was not discussed is not decided for you. It checks whether an existing initiative already covers it, and applies your policies. Adding more initiatives describes all of that in full, including the answers that add nothing.

What it adds lands in Backlog. The card follows the request while it runs, lists every initiative it added once they are there, each linked, and says why if the request was refused or failed, so you can try again. A product takes one such request at a time. If another is already running, the card says so, and tells you when it has finished so you can add yours; it does not start by itself.

Asking for a breakdown still makes one card. “Split this into initiatives” gets one brief describing the whole of the work, because splitting it into ordered, buildable pieces is what the agent behind the card does. A breakdown written in the chat would be a second, weaker version of that agent.

Adding takes the same permission as adding an initiative on the Initiatives page.

Rewriting an initiative’s description

The chat can rewrite the description of any of the product’s initiatives, from any page. Ask for it, “tighten the scope”, “rewrite the acceptance criteria of the login initiative”, and it reads the initiative as it stands and proposes the whole description as it would read afterwards. “This” means the initiative on your screen; when your words fit more than one, it asks which you mean. The card names the initiative, links to it, and shows the proposal against the current text, so you see exactly what changes and where.

The agent is asked to keep everything that was not discussed, every heading and every detail that is still true, in its own words. Read the comparison anyway. It is the review, and applying it is the acceptance.

Applying writes the description to the initiative, and the change shows in the initiative’s activity like any other edit. It is refused in two cases:

• The description changed while the proposal was on screen. The comparison refreshes against the current text, so you never apply a change you have not seen. Look again, and apply again if it is still right.
• The initiative is not open for edits, because an agent holds the turn, a plan written against the current description is waiting for your verdict, or the initiative is done, canceled or archived. What locks, and when explains why.

Writing a document

Some of what you need from a product is a document for someone else: a brief for the steering group, a monthly status report, a one-pager for a new stakeholder, a handover for the team taking over, a security summary for a customer. The chat writes these from your product’s documents, its current state and its code, and hands you the file.

It stays a file

A document the chat writes is not saved to the product. It is not one of the product documents, and it does not go into knowledge.

That is deliberate. Product documents and knowledge are what agents work from. A document the chat writes is built from them: an output, shaped for one reader at one moment. Fed back in, it would become a second, older account of the same facts, and agents would start citing a summary in place of the thing it summarized.

The document stays with the chat it was written in, so you can come back and download it again. A chat shows only its most recent messages, though, so in a long chat an early document drops out of view. Download what you mean to keep.

From request to file

Ask for the document, and say who it is for if you know: “a short brief on where we are, for the steering group”. Before it writes, it needs four things: who reads it, what they need to decide or know from it, what it covers, and roughly how long it is.

Then it shows you an outline and stops. Who the document is for and why, its sections with a line on each, about how long it will be, and the sources it will read. Writing the document is the expensive part, and a wrong reader or a wrong structure means writing it again, so this is the moment to say “add a risks section” or “this is for the board, not the team”. A correction gets you a corrected outline, and a go gets you the document.

“Just write it” skips the questions and the outline, and the document comes straight away.

What you get

A document written for the reader the outline named, in the sections it listed. Its first line names who it is for.

It is built the way an answer is, from what the agent read. Where it says where things stand, it reads the initiatives, the recent runs and the deployments; where it covers risks, it reads the open findings and the documents’ own open questions. What the sources do not cover, the document says is not covered, rather than filling the gap. It ends with a sources section naming each document and version it rests on, and any files from the repository.

Length follows the purpose. A one-pager is one dense page, a brief or a status report is usually three to five pages, and a handover or a security summary can run to ten or more.

If your product already has a document of the kind you asked for, the chat still writes the one you asked for, built from it, and says that the product’s own is the maintained version.

The card

The document arrives as a card with its title and the document itself, which you can read as it renders or as Markdown, and copy as Markdown.

Download it as a PDF, laid out for reading and printing, or as Markdown, the text as written, for a wiki, a repository, or further editing.

Changing it

Ask for the change: “make it shorter”, “add the budget”, “write it for the customer instead”. The agent writes a new version straight away, without another outline, because you are correcting a document you have already seen.

The new version arrives as a new card, open. The earlier one closes and says a newer version replaced it. A replaced version still downloads, as long as it is in view.

A second, different document in the same chat is a new document, not a version of the first, and both stay open.

Your chats

Your chats are yours. The chat history lists the chats you started, across all your products, and you can search it. Nobody else in your organization sees them.

A chat about a product you no longer have access to drops out of your list. Deleting a chat removes it from your list, and it cannot be brought back.

Each chat is its own conversation. The agent remembers what was said earlier in the same chat, not what you settled in another one, so a new topic is better as a new chat than as a turn at the end of an old one.

What it does not do

• Attachments. The chat takes text. Paste in what it should see.
• Other products. A chat stays on its product, and questions about other products, other organizations or Taiga itself are out of its scope.
• Changes without you. Nothing in your product changes until you press a button on a card. A document is only a file for you to download.