> For the complete documentation index, see [llms.txt](https://docs.concurrence.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.concurrence.com/developer-guide/guides/first-console-conversation.md). # First Console Conversation Sign in to the Console, choose a configured test service, start a text conversation, inspect its answer and tool evidence, and end the session. Test a configured agent service in your browser. You will send a synthetic question, inspect the answer and available execution details, and end the conversation. You do not need to install an SDK or create an API key for this walkthrough. If you are still arranging workspace access, use the credential-free local walkthrough in [First Verified Conversation](/developer-guide/guides/first-verified-conversation.md). ## Before You Start Ask your workspace administrator or implementation contact for: * The Console address and account with access to the intended test workspace. * An active text service, with published versions of its linked agent and Context Graph. A voice service opens a voice call in the Playground instead. * Confirmation that the service can answer an ordinary text question without patient context, production write tools, or outbound messaging actions. The Playground uses the service's configured data and tools. A synthetic question alone does not isolate those resources. Use a service reviewed for this exercise. ## 1. Sign In and Choose Your Workspace Open the Console address supplied for your deployment. The US entry point is [console-us.concurrence.com](https://console-us.concurrence.com). Choose **Continue with Google**, or enter your email address and choose **Email me a sign-in link**. Use the account granted access to your workspace. An emailed link opens a **Continue signing in** page; choose **Continue** to finish. Each link works once, expires shortly, and is used only when you choose **Continue**. On the workspace selection screen, select the agreed test workspace; check its name, ID, and region when shown. **Check:** You can enter the intended workspace. If it is missing, ask the administrator to check your membership and Console address. ## 2. Open Your Test Service The Console lists services as agents and their agents as personas. This walkthrough uses the API names, service and agent, and quotes the Console's labels in bold. Open **Evaluate > Playground** and find the agreed service. Use **Find an agent** or the **Text** channel filter to narrow the cards, and **Load more agents** if the service is not in the first group. Only active services appear in this list. Check the service's card. It shows the service's description and channel, and the **Persona** and **Context graph** it runs, each with the version the service's release pins, or **Latest** when no release is set. Confirm these match the test setup with your implementation contact. Choose **Test** on the card. A text service opens the text Playground with a **Start a session** dialog. **Check:** The dialog names the intended service. If it says the agent needs published persona and context graph versions, the service's agent or Context Graph has no published version; resolve that before continuing. ## 3. Start a Text Conversation In **Start a session**, set **Who speaks first** to **User first**. Leave **Test identity** blank for this exercise, and clear any remembered value. For a later test that requires patient context, use only the synthetic entity UUID supplied for that test. If the service declares conversation context, fill in the required fields. Read **Before you start**: this is a real conversation, and the service's tools can read and change connected systems. Then choose **Start text session**. In **User first**, the conversation waits for your message. **Agent first** instead asks the agent to open with its greeting. **Check:** The conversation header shows **Active** and the message field is ready. A blank conversation is expected until you send the first message in **User first**. If the session cannot start, the dialog shows the reason the API returned. ## 4. Send a Question and Inspect the Result Send this question to the reviewed test service: ``` What information would a scheduling team need before considering an appointment change? Do not book or change anything. ``` Press **Enter** to send; **Shift+Enter** inserts a new line. Wait for the answer before sending a follow-up. For this exercise, a useful answer identifies prerequisites such as the existing appointment, the requested change, available alternatives, and authority to make the change. Wording varies by service configuration. If the answer claims to have changed an appointment, stop and investigate the tool evidence with the implementation owner. The conversation shows your message, any state changes and tool calls, and the agent's answer. Open a tool call to see its inputs and result. The header shows the current state. In the inspector beside the conversation: * **Stream** lists each turn's operations, with search and a failed-only filter. * **Run details** summarizes the session and lists anything that needs attention, such as a failed tool. Under **Current configuration**, **Persona** and **Context graph** show the configuration the service's release points at. The Console notes that this does not confirm which version the session ran. Missing details can reflect unavailable evidence; they are not proof that no tool ran. **Check:** Your message and a completed answer are visible. Record the expected result, observed answer, and any unexpected tool activity. An answer about scheduling is not evidence of a booking or of clinical quality. ## 5. End and Record the Conversation Choose **End session** after the answer is complete and any unexpected work has been reconciled. Confirm the **Ended** state and the session summary, and check for an error. If ending fails, the session stays active with the error, so you can choose **End session** again. **New session** starts a separate conversation; use it only when you intend to begin another test. Record the workspace, service, configuration, test time, input, and observed result in your team's test record. When you need independent history and closure verification, inspect the conversation through [Evaluate > Runs](/developer-guide/guides/operate-and-improve.md) and its conversation detail, or use the [SDK starter](/developer-guide/guides/first-verified-conversation.md). The Console's end control closes the conversation; it does not erase retained history or reverse external changes. ## Troubleshooting | What you see | What to check next | | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | The sign-in link says it didn't work | Request a new link from the sign-in page. Each link works once and expires shortly. | | The workspace is missing | Confirm the signed-in account, membership, and Console address with the workspace administrator. | | **No active agents found**, or your service is missing | Choose **View Agents** to check the agreed service's configuration, or **Load more agents** when available. Ask the owner to resolve inactive or missing test configuration. | | The start dialog says the agent needs published persona and context graph versions | Ask the configuration owner to publish a version of each missing agent or Context Graph and check the service's version selection. Publish Context Graphs through the [API or Forge](/developer-guide/guides/build-and-prove.md#build); the Console graph page supports inspection, not editing. | | **Test identity** says the value must be an entity UUID | Clear the remembered value for this context-free exercise, or supply the agreed synthetic entity UUID. | | The session is active but no greeting appears | In **User first**, send the opening message. In **Agent first**, check the start dialog for a reported error. | | Sending or ending reports an error | Preserve the workspace, service, time, and any conversation identifier. Inspect durable history and lifecycle before repeating the action; follow [Troubleshooting](/developer-guide/guides/troubleshooting.md). If ending failed, the session stays active, so you can end it again. | ## Continue * [Build and Prove](/developer-guide/guides/build-and-prove.md) connects service configuration to repeatable testing and release. * [Verify an Integration Action](/developer-guide/guides/verify-an-integration-action.md) adds independent evidence from a configured test system. * [Playground and Interactive Testing](https://docs.concurrence.com/testing/testing/playground) explains voice mode, inspection, and related evaluation tools. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.concurrence.com/developer-guide/guides/first-console-conversation.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.