Agentic work in a controlled loop

Turn your backlog into a running delivery loop.

Every team has important work that never wins sprint priority. Gridly turns your GitLab maintenance backlog into versioned delivery loops. Agents handle the toil; your engineers stay focused on product.

Start NOW! Set up your repository Documentation See the loop

Open your project with an agent and give it the plain Markdown setup guide. It will inspect the project and discuss the development container, Gridly configuration, and issue labels with you.

Your team knows the work. Gridly gives it a safe lane.

Dependency updates, security patches, test coverage, cleanup, and refactoring. You know it matters, but roadmap pressure always wins. Gridly gives these tasks a dedicated delivery lane.

POs write intent

GitLab Issues hold the task, acceptance criteria, discussion, and final status.

Developers define process

Gridly YAML describes which agentic work can run and under what conditions.

Agents do the toil

Workers run OpenCode jobs while people keep review, merge, and product judgement.

The loop is spec-driven work mapped to real execution.

GitLab describes what should happen. Gridly master YAML describes the process. Worker YAML describes where it can run. OpenCode executes and writes the result back.

Gridly loop logo
Controlled agentic deliveryGridly keeps process and state around the worker run.
1

GitLab specs and tasks

Issues carry the work description, acceptance notes, labels, comments, and human decisions.

2

Gridly master YAML

The server config maps labels to job profiles: image, model, prompt, match rules, timeout.

3

Gridly worker YAML

The worker config defines runtime, workspace, network ports, labels, and available capacity.

4

OpenCode run and review

The worker runs the job, streams logs, returns a result, and GitLab remains the review surface.

The agent does bounded work. Gridly records state. Humans decide what ships.

Gridly crew coordinating a maintenance program Gridly dashboard view
Case study

Do the work nobody has time for.

Every team has maintenance work that affects reliability but never makes the roadmap: dependency updates, security checks, docs, test coverage, refactoring, and cleanup. Gridly processes it while your engineers stay focused on product delivery.

1. Collect the toilWe moved this work into GitLab Issues with clear labels and simple acceptance notes.
2. Let Gridly route itGridly matched those labels to versioned YAML workflows and started processing the queue.
3. Use idle capacityOld hardware runs dev containers with OpenCode workers, orchestrated by Gridly.
4. Spend unused tokensOutside working hours, unused tokens turn into maintenance work that nobody had time to do.
Run it

Start with one project and one worker.

Download a prebuilt Gridly binary for Linux or macOS, then use the repository setup guide to prepare your project and worker.

Download Gridly Repository setup guide

Give your agent this request in the target repository:

Read https://openforge-gridly.pages.dev/repository-setup-guide.md and help me prepare this repository for Gridly. First inspect the project and discuss the setup choices with me.
GRIDLY_VERSION=v0.8.1
GRIDLY_PLATFORM=linux-amd64
GRIDLY_PACKAGES=https://gitlab.com/api/v4/projects/openforge%2Fgridly-scheduler/packages/generic/gridly
curl --fail --location \
  "$GRIDLY_PACKAGES/$GRIDLY_VERSION/gridly-$GRIDLY_PLATFORM" \
  --output gridly
chmod +x gridly
./gridly help

This downloads the published v0.8.1 binary for Linux amd64. Set GRIDLY_PLATFORM to linux-arm64, darwin-amd64 (Intel Mac), or darwin-arm64 (Apple Silicon) for your system.

Next, download the matching server config and worker config and follow the setup guide before starting jobs. Version v0.8.1 uses single-project server settings; repository discovery requires a version that supports it.