# Answer Support Tickets from a Go Codebase Yes. Your backend sends each ticket to the API, an agent traces the behaviour through your Go code, and the reply comes back as JSON on your webhook. [Run this on Rush](https://cloud.getrush.ai/run/answer-support-tickets-from-code/go/), in a Project that has your repository. ## What the agent does Your help desk receives a ticket and starts one run for it: the product's repository in `resources`, the customer's question in the prompt. The agent clones the repository into its own cloud sandbox and answers from code. In a Go product like `miniflux/v2`, it reads `go.mod` (module `miniflux.app/v2`, Go 1.26), sees the packages under `internal/`, and finds feed polling split between `internal/cli/scheduler.go`, `internal/storage/batch.go`, `internal/reader/handler/handler.go` and `internal/model/feed.go`. For "why are some feeds refreshed less often than the interval I set?", the agent starts at `Feed.ScheduleNextCheck` in `internal/model/feed.go`. The interval begins at `SCHEDULER_ROUND_ROBIN_MIN_INTERVAL`, or under the `entry_frequency` scheduler at a value derived from the feed's weekly entry count. Then `interval = max(interval, refreshDelay)`: a feed's own refresh delay can push the next check later than the configured interval, up to `SCHEDULER_ROUND_ROBIN_MAX_INTERVAL`. In `internal/reader/handler/handler.go` that delay is `max(feedTTLValue, cacheControlMaxAgeValue, expiresValue)`, the RSS ``, the `Cache-Control` max-age and the `Expires` header. It reads the defaults instead of guessing them. `internal/config/options.go` sets `POLLING_FREQUENCY` to 60 minutes, `BATCH_SIZE` to 100, `POLLING_SCHEDULER` to `round_robin`, the round robin minimum to 60 minutes and the maximum to 1440 minutes, and `POLLING_PARSING_ERROR_LIMIT` to 3. The scheduler in `internal/cli/scheduler.go` wakes every polling frequency and takes one batch of feeds whose next check has passed, so an instance with many feeds can fall behind. `WithErrorLimit` in `internal/storage/batch.go` leaves out feeds that have failed the parsing error limit, which is a second reason a feed stops refreshing. The agent writes the reply in the shape the prompt asks for: two short paragraphs a self-hosting customer can act on, naming the settings to check, the files and lines that prove each statement, and a confidence level. It changes no code. Where the answer depends on the customer's feed, such as a long ``, it says which header or field to look at. ## Start it with one API call `POST https://api.prix.dev/o/{org}/sessions` ```json { "agent": "codex", "input": "A customer asks: why are some feeds refreshed less often than the interval I set? Find the answer in this repository's code, not its docs: start at Feed.ScheduleNextCheck in internal/model/feed.go, follow the refresh delay in internal/reader/handler/handler.go, the batch scheduler and the parsing error limit, and read the defaults in internal/config/options.go. Reply with JSON: answer (two short paragraphs a customer can read), files (paths and lines that prove it), and confidence. Do not change code.", "resources": [ { "url": "https://github.com/your-org/your-app" } ] } ``` 1. **Get an API key.** In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token. 2. **Send the request.** POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox. 3. **Read what came back.** Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory. ## What comes back The run's final answer is the JSON object the prompt asks for. `answer` explains in plain words that a feed's own TTL or cache headers can stretch its interval, that the batch scheduler handles a fixed number of feeds per pass, and that feeds over the error limit are skipped. `files` points at `internal/model/feed.go`, `internal/reader/handler/handler.go`, `internal/cli/scheduler.go`, `internal/storage/batch.go` and `internal/config/options.go` with line numbers. `confidence` comes with the one thing to check when it is not high. Your webhook gets it as `data.result` in the `run.completed` payload, and `GET /o/{org}/sessions/{id}` returns the same `result` at any time. Your backend parses the object and puts the answer on the ticket as a draft. A support person checks the cited defaults against the customer's environment, for instance whether they set `POLLING_SCHEDULER=entry_frequency`, before sending it. The session keeps every file the agent read and every search it ran, so an engineer can see the path from the question to the answer. That record is what makes the next similar ticket faster: the same files, the same lines, already found. ## Run it on every new support ticket Your help desk's webhook calls `POST /o/{org}/sessions` once per ticket, with the question in `input`. Using the ticket id as the `Idempotency-Key` makes a duplicate delivery return the run already started instead of a second one. Point the API key's webhook at your backend to get each reply when its run finishes, signed per Standard Webhooks so you can verify it came from Rush. When the customer replies with their configuration, send it as a follow-up message to the same session and the agent answers with the code it has already read. ## Why run it on Rush? A question about polling intervals in a Go service sits across five packages and a configuration file. A Rush run starts with the repository cloned in its own sandbox and the tools to search it, and returns a reply your backend can parse, without a developer stopping their own work to trace it. Tickets arrive in bursts and each one gets its own run, side by side. Every reply cites the lines it relies on, and the session keeps the full record of the investigation, so support can send a precise answer and engineering can check it in seconds. ## Frequently asked questions ### Does the agent run the Go code or just read it? For this question reading is enough, and the prompt says not to change code. The sandbox has a shell, so if a ticket is easier to answer by running `go test` on one package, say so in the prompt and the transcript will show the output. ### What if the answer depends on the customer's configuration? The reply names the setting that decides it, such as `POLLING_SCHEDULER` or `BATCH_SIZE`, and the default the code uses. Put the customer's values in the prompt when you have them and the answer can be specific. ### Can I use Codex instead of Claude Code? Yes. `agent` takes `claude`, `codex` or `opencode`, and the request on this page uses `codex`. The repository, the prompt and the shape of the result stay the same. ### How large can the reply be? The webhook carries `result` up to 16 KiB. A two-paragraph answer with a list of files is well under that; past the limit the webhook leaves `result` out and the session read returns it.