Skip to main content

Quick Start

This guide validates a new installation by configuring one model, creating a workspace, and running a first session and ticket.

0. Sign in and activate​

Open the HTTPS URL of your installation and sign in through the configured identity provider. The first user to sign in becomes Admin — complete this with the intended administrator account before opening access to others. If the Activate Polygent screen appears, install the license first; see Licensing.

1. Pick a model​

The built-in Polygent Code agent needs only a model and its credentials.

  1. Open Developer Tools → PolygentCode → Settings.
  2. Under Backend Connections, enter the API key for your model provider.
  3. Under Model Configuration, make sure the model is visible and assign it to the Default (Daily use) tier.

Command-line models also need their tool installed and signed in on every session host — see Models & Backends.

2. Create a workspace​

A workspace binds Polygent to one or more Git repositories and is the unit of access isolation.

  1. Open Settings → Workspaces and select Create Workspace.
  2. Enter the Name, Git Repository URL, Personal Access Token (PAT), and Repository Default Branch (for example main).
  3. Select Create. Polygent checks repository access and the branch before saving.
  4. On the workspace Users tab, add the people who will work in it (administrators have access automatically; other users, including a non-admin creator, must be added).
  5. Optionally configure the ticket Source (GitHub or Azure DevOps / TFS) on the Tickets tab. See Ticket Sync.

3. Run your first session​

A session is an agent conversation running in its own Git working copy, so concurrent sessions never share a working directory.

  1. In My Work in the sidebar, select + to open New.
  2. Choose a bot — for example Help With Polygent, Debugger, or Request — or Chat / Develop when your administrator has enabled those cards (ShowChatInNewMenu / ShowDevelopInNewMenu).
    • Develop — isolated working copy for changes that will be reviewed, committed, and pushed.
    • Chat — persistent working copy for questions and ongoing conversation.
  3. Select the workspace, branches, and model.
  4. For Develop sessions, optionally enable Auto Code Review and Auto Verification.
  5. Type your first message — use @ to mention files and / for slash commands and skills.

Agent messages, tool calls, file changes, and cost appear live. Start another session the same way to work in parallel; each gets its own working copy.

4. Create a ticket​

Tickets turn agent work into trackable, queued work with human approvals.

  1. In My Work, select + and choose Create Ticket (requires Manage Tickets).
  2. Enter the title and description, and optionally attach files.
  3. Select Create to save it as Pending, or Create & Start to queue it immediately. In the start dialog choose the model, workflow, branches, developer and QA assignees, and priority.

The ticket starts when an eligible session host has ticket capacity. Tickets move through Pending → Queued → (Plan) → Implementation → Developer Approval → QA Approval → Pull Request → Completed, and can end in Failed, Canceled, or Merge Conflicts.

Tip: The Request bot turns a plain-language description into a complete ticket.

Use Start Ticket Templates to save repeatable start configurations.

5. Review and merge​

Developer and QA approval are explicit human checkpoints before delivery.

  1. Open the ticket from Tickets or My Work when it reaches Developer Approval or QA Approval.
  2. Approve, or reject with feedback (text and attachments).
  3. After approval, Polygent creates a pull request (GitHub or Azure DevOps) or merges directly, according to the workspace Merge Mode.
  4. Pull-request status (Open, Waiting, Merged, Closed, Conflicts, Failed to Create) is tracked live.

With a Deployment Worker, QA can test a branch in a preview slot before approving.

6. Plan a feature​

The Planner turns a plain-language request into a reviewed specification and a ticket.

  1. In My Work, select + and choose Plan.
  2. Pick the workspace, model, and branches; write the description; attach context files.
  3. Choose an Auto Answer mode (Disabled, MVP, Balanced, Features Rich, or Custom).
  4. Step through Configuration → Understanding → Clarifications → Recommendations → Specifications → Review.
  5. Edit the result on Review, then Create Ticket or Create & Start.

7. Open a session in your IDE (optional)​

IDE integration moves Develop-session work between the server and your local clone.

  1. On the session page, select Open in IDE and run the Bash or PowerShell one-liner; it applies the session's changes to your local clone.
  2. Send local edits back with Upload from IDE, or push to your own remote and use Pull from IDE (Remote).

Transfer tokens are single-use and expire after 5 minutes.

8. Schedule recurring work​

Automations run sessions on a schedule, once, in a loop, on demand, or from an HTTP call. See Automations.

9. Capture team knowledge​

Two features turn sessions into reusable knowledge.

  • Insights — findings extracted from completed Develop sessions that you can dismiss or turn into tickets. See Insights.
  • Memory — per-workspace stores that agents read and write through built-in tools. See Memory.

10. Run a Round Table​

A round table discusses a topic from several AI perspectives.

  1. Ask an administrator to enable personas for the workspace under Settings → Personas (built-in personas start disabled).
  2. In My Work, select + and choose Round Table, then pick the personas.
  3. Send a message, call a vote, or generate a summary; export to Markdown or text, or create a ticket or plan from the discussion.

What's next​