Version: v1.19.0 | Date: 2026-02-22 | Status: Active development, single-developer project

This document is an honest, data-grounded comparison of Gravity against the February 2026 project management landscape, with specific attention to AI agent integration. It replaces the previous version which described an outdated architecture (Neovim config sync + skills + OpenProject MCP sidecar).

What Gravity Is Now
Architecture Overview
Competitive Landscape: February 2026
Feature Matrix
Agent Integration: Detailed Comparison
Self-Hosted Alternatives
Cost Analysis
What Makes Gravity Unique
The Unbuilt Market Gap
Genuine Weaknesses
Genuine Strengths
What To Stop Reimplementing
What To Keep
Roadmap Through v1.29
Strategic Assessment

What Gravity Is Now

Gravity is a self-hosted, open-source project management platform designed for humans and AI agents as equal citizens. It is not a plugin, not a sidecar, not a configuration sync tool. It is a standalone PM system with an embedded event engine that dispatches AI agent work as a first-class operation.

Repository: git.bros.ninja/mike/gravity (Go monorepo with go.work)

Component	Language	LOC	Purpose
`gravity-pm`	Go	~13,350	REST API, MCP server, OIDC auth, templ/htmx UI, domain event publishing
`event-engine`	Go	~5,730	NATS subscriber, Forgejo webhook receiver, durable job queue, Claude dispatcher, append-only event log
`gravity-migrate`	Go	Tool	Database migration runner
Total	Go	~19,080	Two services, single compose deploy

Key direct dependencies (from go.mod, not transitive):

gravity-pm	event-engine
`templ` (HTML templating)	`watermill` + `watermill-nats` (event bus)
`go-chi` (HTTP router)	`go-chi` (HTTP router)
`pgx` (PostgreSQL driver)	`pgx` (PostgreSQL driver)
`go-oidc` + `oauth2` (OIDC auth)	`nats.go` + `nats-server` (messaging)
`go-redis` (Valkey sessions)	`goose` (migrations)
`goose` (migrations)	`x/sync` (semaphore for concurrency)
`nats.go` (event publishing)	`google/uuid` (job IDs)

Direct dependencies: 8 (gravity-pm) + 10 (event-engine). Transitive: ~55 unique modules per service.

Architecture Overview

                      Forgejo Webhooks
                            |
                            v
+-------------------+  NATS JetStream  +--------------------+
|    gravity-pm     |  <------------>  |   event-engine     |
|                   |                  |                    |
| REST API (chi)    |  gravity.pm.>    | Watermill sub      |
| MCP Server (stdio)|                  | @agent cmd parse   |
| OIDC Auth         |  Outbox Poller   | JetStream job queue|
| Valkey Sessions   |  ------------->  | Concurrency limiter|
| templ/htmx UI     |                  | Claude dispatcher  |
| Domain Events     |                  | Event log writer   |
| Wiki, News, Time  |                  | Job reaper         |
+--------+----------+                  +--------+-----------+
         |                                      |
         v                                      v
   PostgreSQL 16                          PostgreSQL 16
   (pm tables)                           (event log, jobs)

Infrastructure (all containers, single docker compose up):

Container	Image	Purpose
`postgres`	`postgres:16-alpine`	Primary data store
`nats`	`nats:2.11-alpine`	JetStream event bus + job queue
`valkey`	`valkey/valkey:8-alpine`	Session store
`gravity-pm`	Custom Go binary	PM application
`event-engine`	Custom Go binary	Event processor + agent dispatcher
`authelia`	(Planned/configured)	OIDC identity provider
`caddy`	(Planned/configured)	Reverse proxy + TLS

Event Flow (PM action to agent dispatch):

User creates/updates work package in gravity-pm
Handler writes domain event to transactional outbox (same DB transaction)
Outbox poller publishes event to NATS JetStream (gravity.pm.> subjects)
event-engine's Watermill subscriber receives event
Engine parses @agent <command> from event body
Matched handler submits job to JetStream-backed durable queue (AGENT_JOBS stream)
Job consumer pulls message, acquires concurrency slot (per-type + global semaphore)
Processor transitions job: queued -> claimed -> running -> completed/failed/dead
Claude dispatcher invokes claude -p with constructed prompt, tool allowlist, max turns, timeout
Result published to AGENT_JOBS.result subject; job status updated in PostgreSQL
Event log writer persists all events to pm_event_log (append-only, durable consumer)

Competitive Landscape: February 2026

Tier 1 -- Agent-First Architecture

These platforms treat AI agents as peers to human users: agents have identities, can be assigned work, and interact through the same interfaces humans use.

Platform	Agent Model	Deployment	Pricing	Open Source
Linear	Agent OAuth identities (`actor=app`), assignable/mentionable, Agent Interaction SDK, Agent Guidance	Cloud only	$8/seat/month	No
Plane	MCP server (MIT), agent run lifecycle, @mention dispatch	Self-hostable (AGPL-3.0)	Free CE / Cloud Pro	Partial (AI features cloud/enterprise only)
Gravity	PM-native event source, JetStream job queue, Claude dispatch, MCP server (embedded)	Self-hosted only	Infrastructure cost only	Yes (full features)

Tier 2 -- AI Teammates

Agents perform work through a separate subsystem. The agent is a feature of the platform, not a peer within it.

Platform	Agent Model	Self-Hostable	Pricing
Asana AI Teammates	12 pre-built agents, team-oriented, governance controls	No	Enterprise tier
ClickUp Super Agents	Autonomous agents, multi-model support, memory systems	No	Enterprise tier
Wrike AI Agents (Feb 5, 2026)	Agent Builder, agent chaining, custom workflows	No	Enterprise tier
Dart AI (YC)	Autonomous task execution, chat-driven interface	No	Cloud only

Tier 3 -- AI-Enhanced

AI assists humans through copilot/assistant patterns. AI is not a workspace member.

Platform	AI Feature	Self-Hostable	Notes
Jira/Rovo	Assistant/copilot, not workspace member	Cloud only	Atlassian ecosystem lock-in
Microsoft Planner	Project Manager Agent	No	M365 subscription required
Monday.com	AI automations	No	Not agent-oriented

Feature Matrix

Core PM Features

Feature	Gravity v1.19	Linear	Plane CE	OpenProject CE	Jira Cloud
Work packages/Issues	Yes	Yes	Yes	Yes	Yes
Epics/Summary tasks	Yes	Yes (Projects)	Yes (Modules)	Yes	Yes
Versions/Milestones	Yes	Yes (Cycles)	Yes (Cycles)	Yes	Yes (Releases)
Story points	Yes	Yes (Estimates)	Yes	Yes	Yes
Time tracking	Yes (built-in)	No	No	Yes	Via plugin
Wiki	Yes (built-in)	No	Yes (Pages)	Yes	Confluence
News/Announcements	Yes	No	No	Yes	No
Board view	Yes (Kanban)	Yes	Yes	Yes	Yes
Custom theming	Yes	No	No	No	No
PR URL linking	Yes	Yes (Git)	Yes (Git)	Yes (Git)	Yes (Dev panel)

Agent Integration Features

Feature	Gravity v1.19	Linear	Plane	Asana	ClickUp
Agent identity model	Not yet (planned v1.20+)	OAuth app identity	Agent users	AI teammates	Super agents
Agent as assignee	Not yet (planned)	Yes	Via @mention	Yes	Yes
MCP server	Yes (embedded, stdio)	No	Yes (MIT, separate)	No	No
Event-driven dispatch	Yes (NATS JetStream)	Webhooks only	Webhooks only	Webhooks only	Webhooks only
Job queue with retry	Yes (durable, backoff)	N/A	N/A	N/A	N/A
Concurrency limiting	Yes (per-type + global)	N/A	N/A	N/A	N/A
Dead-letter handling	Yes	N/A	N/A	N/A	N/A
Agent cost tracking	Not yet (planned)	No	No	No	No
Multi-provider support	Not yet (Claude only)	N/A	Anthropic + OpenAI	Multi-model	Multi-model
Self-hosted AI features	Yes (all features)	N/A	No (enterprise only)	N/A	N/A

Infrastructure and Operations

Feature	Gravity v1.19	Linear	Plane CE	OpenProject CE
Deployment	`docker compose up` (8 containers)	Cloud managed	Docker Compose	Docker Compose
Database	PostgreSQL 16	Proprietary	PostgreSQL	PostgreSQL
Event bus	NATS 2.11 + JetStream	Internal	Redis	None
Session store	Valkey 8	Internal	Redis	Rails sessions
Auth	OIDC (Authelia), local email+password, dev mode	SSO, Google, SAML	Google, GitHub, email	LDAP, SAML, OIDC
CI/CD	Forgejo Actions (vet, test, build, publish)	N/A	GitHub Actions	GitHub Actions
Container registry	Forgejo built-in	N/A	Docker Hub	Docker Hub

Agent Integration: Detailed Comparison

Linear (Market Leader in Agent-First PM)

Linear has the most mature agent integration as of February 2026:

Agent OAuth identities: Agents authenticate as actor=app with dedicated OAuth scopes. They appear in the workspace as distinct actors, not impersonating human users.
Assignable/Mentionable: Agents can be assigned to issues and @mentioned in comments, triggering agent actions through Linear's event system.
Agent Interaction SDK: Official SDK for building agent integrations with typed event handling.
Agent Guidance: Configuration that tells agents how to behave within a workspace (conventions, naming, workflow rules).

What Linear does NOT have: Self-hosting, open source, PM-native event bus, durable job queues, embedded MCP server. Linear agents integrate via webhooks and API polling, not through an event-driven architecture internal to the PM itself.

Plane (Closest Open-Source Competitor)

Plane is the most relevant comparison for Gravity:

MCP Server: MIT-licensed, provides tool definitions for issue CRUD, cycles, modules. Separate process, not embedded.
Agent Run Lifecycle: Tracks agent execution state within the platform.
@mention Dispatch: Typing @agent in comments triggers agent workflows.

Critical distinction: Plane's AI features (Copilot, agent dispatch, AI summaries) are not available in the community edition. They require Plane Cloud or Enterprise. Plane CE is a PM without AI agent features. Gravity ships all features in the open-source version with zero feature gating.

Gravity (Current State)

Gravity's agent integration is architecturally different from all competitors:

PM-native event source: Domain events (work_package.created, version.updated, etc.) are emitted from within the PM's transaction boundary via a transactional outbox pattern. This is not a webhook bolted onto the side; it is part of the write path.
Watermill + NATS JetStream: Events flow through a proper message bus with guaranteed delivery, subject-based routing, and stream retention. No public project management tool uses this combination.
Durable job queue: Agent jobs are backed by JetStream with explicit ack, configurable backoff (10s, 30s, 2m), max delivery (4 attempts), and dead-letter handling. Failed jobs are tracked in PostgreSQL with full state history.
Concurrency control: Per-type and global semaphore limiting prevents agent overload. The Limiter uses golang.org/x/sync/semaphore for blocking slot acquisition.
Job reaper: Background goroutine finds orphaned jobs (claimed/running but stale beyond configurable threshold) and marks them failed.
Embedded MCP server: 17 tools (list/get/create/update work packages, versions, wiki, news, time entries, comments, events) served over JSON-RPC 2.0 stdio, built into the gravity-pm binary itself.

Current limitation: Dispatch is via claude -p shell-out (see What To Stop Reimplementing).

Self-Hosted Alternatives

For teams that require self-hosting, the landscape is thin:

Platform	License	AI Agent Features	Active Development	Maturity
Plane CE	AGPL-3.0	None in CE	Yes (commercial)	Production
OpenProject CE	GPL-3.0	On roadmap only	Yes (commercial)	Production (15+ years)
Leantime	AGPL-3.0	AI assistant (basic)	Yes	Production
Taiga	MPL-2.0	None	Maintenance mode	Stable
Vikunja	AGPL-3.0	None	Yes	Production
Gravity	TBD	Full (all features)	Yes (solo dev)	Alpha

The self-hosted market has a clear gap: no production-ready, open-source PM platform ships AI agent dispatch as a core feature without enterprise/cloud gating. Gravity is the only project attempting this, but it is six days old and has not been validated beyond the developer.

Cost Analysis

Monthly Infrastructure Cost (10-Person Team)

Solution	Monthly Cost	Notes
Gravity (self-hosted)	~$400	VM + storage + AI API tokens. Fixed regardless of team size.
Linear	$80	$8/seat/month. No self-hosting. Agent tokens additional.
Plane Cloud Pro	$70	$7/seat/month. AI features require Pro+.
Jira Cloud Standard	$80	$8.15/seat/month. Confluence additional.
Asana Business	$250	$24.99/seat/month for AI features.
ClickUp Business	$120	$12/seat/month. AI features at Business tier.

Monthly Infrastructure Cost (50-Person Team)

Solution	Monthly Cost	Notes
Gravity (self-hosted)	~$400	Same infrastructure. AI API tokens scale with usage, not seats.
Linear	$400	Scales linearly with seats.
Plane Cloud Pro	$350	Scales linearly with seats.
Jira Cloud Standard	$387	Volume discounts apply.
Asana Business	$1,250	Scales linearly.
ClickUp Business	$600	Scales linearly.

Gravity's cost advantage appears at scale because infrastructure is fixed-cost while SaaS is per-seat. The break-even point against Linear is approximately 50 users. Below that, Linear is cheaper AND more mature.

What Makes Gravity Unique

These are capabilities that, to the best of research, no other PM platform currently offers:

1. PM-Native Event Source

Every domain operation in gravity-pm emits a structured event via transactional outbox:

// From gravity-pm/internal/event/publisher.go
// Events are written to the outbox in the same DB transaction as the domain write.
func (p *NATSPublisher) PublishOutbox(ctx context.Context, tx pgx.Tx, evt Event) error {
    return p.store.InsertOutboxEvent(ctx, tx, evt)
}

The outbox poller then publishes to NATS JetStream (GRAVITY_PM_EVENTS stream, gravity.pm.> subjects, 1GB retention, 7-day max age, file-backed storage). This guarantees no events are lost even if NATS is temporarily down.

Competitors use webhooks (fire-and-forget, no guaranteed delivery, no replay) or external integrations.

2. Watermill + NATS + AI Agent Dispatch

The event-engine uses Three Dots Labs' Watermill as the event processing framework with NATS JetStream as the transport. This combination provides:

Subject-based wildcard subscription (gravity.pm.>)
At-least-once delivery with explicit ack
Stream retention for replay
Consumer groups for horizontal scaling

No public PM project uses Watermill + NATS for agent orchestration.

3. Go-Native, Single-Binary Deployment

Each service compiles to a single static binary. Most agent orchestration tools (LangChain, CrewAI, AutoGen) are Python or TypeScript. Gravity's Go implementation means:

No runtime dependencies (no Python, no Node.js, no JVM)
Small container images (Alpine-based)
Predictable memory usage under load
goroutine-based concurrency (no async/await complexity)

4. Zero Feature Gating

All features ship in the open-source version. Compare:

Platform	Community/Free	Cloud/Enterprise Only
Gravity	Everything	N/A
Plane	Basic PM	AI Copilot, Agent dispatch, AI summaries
OpenProject	Basic PM	Enterprise boards, 2FA, LDAP sync
GitLab	Basic PM	AI features, advanced CI, security

5. Embedded MCP Server

The MCP server is compiled into gravity-pm, not a separate sidecar or external integration:

// 17 tools registered: list/get/create/update work_packages, versions,
// wiki, news, time_entries, comments, events
// JSON-RPC 2.0 over stdio, protocol version 2024-11-05
func New(baseURL, token string) *Server {
    s := &Server{tools: make(map[string]Tool), ...}
    s.registerTools()
    return s
}

This means any MCP client (Claude Code, Cursor, Windsurf, etc.) can interact with Gravity's full PM surface area through a single stdio connection.

The Unbuilt Market Gap

These capabilities do not exist in any PM platform as of February 2026. They represent the actual frontier, not incremental improvements:

Agent-to-Agent Dispatch Within the PM

No platform supports: Agent A creates a work package, assigns it to Agent B, Agent B automatically picks it up and begins work. Current agent integrations are human-initiated. The PM itself does not orchestrate between agents.

Agent Self-Management

No platform supports: An agent creates its own work packages, estimates effort, manages its own backlog, and reports status -- all through the same interfaces humans use. Agents today are tools invoked by humans, not autonomous participants.

True API Parity Between Humans and Agents

Every platform has API asymmetry: agents authenticate differently, have different rate limits, access different endpoints, or are tracked through different audit systems. True parity means an agent's API token grants identical capabilities to a human's session.

Multi-Agent Orchestration Native to PM

Agent orchestration today requires external frameworks (LangGraph, CrewAI, AutoGen). No PM platform has built orchestration into its core: defining agent roles, routing work between agents, managing agent dependencies, tracking agent costs per task.

Agent Cost Tracking Per Task/Version/Provider

No platform tracks: "This sprint cost $47.23 in Claude API calls across 12 agent-dispatched tasks, with Agent A consuming $31.10 and Agent B consuming $16.13." This data is essential for enterprise adoption of AI agents in project management.

Genuine Weaknesses

These are real problems, not hedged disclaimers:

Weakness	Severity	Details
6 days old	Critical	Created 2026-02-17. No production deployment beyond the developer.
Single developer	Critical	One person built and validated everything. No external code review.
Test coverage ~28%	High	27 test files, ~6,350 lines of test code against ~19,080 lines of application code. Auth handlers largely untested.
Error handling: silent discards	High	Multiple `json.Unmarshal` calls discard errors (e.g., MCP tool handlers). Event marshaling errors in publisher are ignored.
Security gaps	High	Being addressed in v1.19.1: TLS skip verify in dev, optional webhook signature auth, hardcoded credentials in dev mode.
Logging inconsistent	Medium	Mix of `log.Printf` and `slog` across services. Standardization planned.
No real-world soak time	High	Zero hours of multi-user production load. No data on memory leaks, connection pool exhaustion, NATS backpressure behavior.
Frontend: templ/htmx	Medium	Server-rendered HTML. No real-time updates (WebSocket planned v1.21). SPA migration planned v1.26-v1.29.
Claude-only dispatch	Medium	The dispatcher shells out to `claude -p`. No multi-provider support, no SDK integration, no cost tracking.
No agent identity model	Medium	Agents do not have distinct identities in the PM. No agent-as-assignee data model.
Sprint-built with AI assistance	Context	Heavy use of Claude Code during development. Code quality reflects rapid iteration, not careful craftsmanship.

Genuine Strengths

These are verifiable, not aspirational:

Strength	Evidence
Architecture is research-backed	Linear sync engine patterns, NATS JetStream semantics, Watermill event sourcing patterns were studied before implementation. Not invented from scratch.
Lean dependencies	8 direct deps (gravity-pm), 10 direct deps (event-engine). ~55 unique transitive modules per service. Compare: typical Node.js PM has 500-1500 transitive deps.
Event-driven from day one	Transactional outbox, JetStream streams, durable consumers, subject-based routing. This was the foundation, not a retrofit.
Clean Go monorepo	`go.work` with `apps/event-engine`, `apps/gravity-pm`, `tools/gravity-migrate`. Standard Go project layout.
Professional CI/CD	Forgejo Actions: vet, test, build on PR/push. Version detection from `VERSION` file, auto-tagging, container registry publish, release promotion (draft -> published).
Durable job queue	JetStream-backed with explicit ack, configurable backoff (10s/30s/2m), max 4 deliveries, dead-letter handling, orphan reaping. This is production-grade queuing infrastructure.
Concurrency control	Per-type + global semaphore limiting. Prevents agent API cost explosion. Not found in any competitor's agent integration.
Flat cost	~$400/month regardless of team size. AI API costs scale with usage, not seats.
17-tool MCP server	Work packages, versions, wiki, news, time entries, comments, event history. Full PM surface area accessible to any MCP client.

What To Stop Reimplementing

These components should be replaced with mature, maintained alternatives. The current implementations work but will accumulate technical debt faster than hand-maintaining them is worth.

1. Claude Dispatcher: Use Claude Agent SDK Instead of Shell-Out

Current: exec.CommandContext(ctx, "claude", args...) in dispatch/claude.go

// Current implementation -- shells out to claude CLI
cmd := exec.CommandContext(ctx, "claude", args...)
cmd.Stdout = &stdout
cmd.Stderr = &stderr
if err := cmd.Run(); err != nil {
    return "", fmt.Errorf("claude command failed: %w\nstderr: %s", err, stderr.String())
}

Problem: No structured output parsing, no streaming, no token counting, no cost tracking, no tool use interception, process overhead per dispatch.

Replace with: Anthropic's Claude Agent SDK (or raw Messages API with tool use). This gives:

Structured responses with token counts
Streaming for long-running agents
Tool use interception (agent can call MCP tools mid-conversation)
Cost calculation per request
No subprocess overhead

2. Multi-Provider Dispatch: Use LiteLLM Instead of Building It

Current: Claude-only, hardcoded in processor.go:

func (p *Processor) dispatch(ctx context.Context, msg JobMessage) (string, error) {
    switch msg.JobType {
    case "claude_dispatch":
        return p.dispatchClaude(ctx, msg)
    default:
        return "", fmt.Errorf("unknown job type: %s", msg.JobType)
    }
}

Planned v1.20: Multi-provider support (Anthropic, OpenAI, Ollama).

Replace with: LiteLLM (or a similar proxy). LiteLLM provides:

Unified API across 100+ providers
Automatic retries and fallback
Cost tracking per request/provider
Rate limiting per provider
Go client available

Building multi-provider dispatch from scratch is a multi-month effort for one developer. LiteLLM solves it today.

3. MCP Server: Use Official MCP SDK Instead of Hand-Rolled JSON-RPC

Current: Hand-written JSON-RPC 2.0 parser in mcp/server.go:

// Hand-rolled JSON-RPC dispatch
switch req.Method {
case "initialize":
    s.handleInitialize(req)
case "tools/list":
    s.handleToolsList(req)
case "tools/call":
    s.handleToolsCall(req)
// ...
}

Problem: Missing MCP features (resources, prompts, sampling, notifications, progress reporting). No protocol version negotiation. Error handling gaps (marshal errors silently discarded).

Replace with: Official MCP Go SDK (github.com/modelcontextprotocol/go-sdk or community equivalent). Benefits:

Full protocol compliance (resources, prompts, sampling)
Built-in error handling
Protocol version negotiation
Progress reporting for long operations
Community-maintained, specification-aligned

What To Keep

These components are the genuine competitive advantages. They should be maintained, extended, and documented, not replaced.

1. Watermill + NATS Event Engine

The Watermill + NATS JetStream combination is the architectural foundation that makes Gravity's agent integration fundamentally different from competitors:

Transactional outbox: Events are written atomically with domain writes. No event loss.
Subject-based routing: gravity.pm.> wildcard subscription. New event types require zero consumer changes.
Stream retention: 1GB, 7-day file-backed storage. Events can be replayed.
Durable consumers: Named consumers (event-log-writer, job-worker) survive restarts.
At-least-once delivery: Explicit ack with configurable redelivery.

This is not something any competitor has. Linear uses webhooks. Plane uses Redis pub/sub. OpenProject has no event bus. Keeping and extending this is the correct strategic choice.

2. Go Deployment Simplicity

Two static Go binaries, Alpine containers, docker compose up. This is a genuine operational advantage:

No Python/Node.js runtime to manage
No dependency conflicts at deploy time
Predictable resource consumption
Single GRAVITY_VERSION env var controls both services

Do not migrate to a language with heavier deployment requirements. The Go choice pays compounding dividends in operational simplicity.

3. PM-Native Event Source

The pattern of emitting domain events from within the PM's write path (not via webhooks after the fact) is the key insight that enables everything else:

Human/Agent action
  -> HTTP handler
    -> Domain write (PostgreSQL)
    -> Outbox write (same transaction)
  -> Outbox poller
    -> NATS JetStream publish
      -> Event engine subscription
        -> Command parsing
          -> Job queue submission
            -> Agent dispatch

This chain is impossible to replicate via webhooks because webhooks are fire-and-forget, have no guaranteed delivery, no replay, and no transactional consistency with the domain write. Keep this. This is the moat.

4. JetStream-Backed Durable Job Queue

The job queue implementation is production-grade infrastructure:

Explicit ack policy with configurable backoff: [10s, 30s, 2m]
Max 4 delivery attempts before dead-letter
Per-type and global concurrency semaphores
Orphan job reaper (configurable stale age and interval)
Full state machine: queued -> claimed -> running -> completed/failed/dead
Job results published back to NATS for downstream consumption

This would take months to rebuild if replaced with a simpler approach. It is already built and tested. Keep it.

Roadmap Through v1.29

Version	Focus	Key Deliverables
v1.19.1	Security and Quality	TLS enforcement, webhook auth required, credential externalization, slog standardization, error handling audit, test coverage gates, OpenTelemetry traces
v1.20	Multi-Provider and Plugins	Anthropic SDK integration (replace shell-out), OpenAI + Ollama dispatch, plugin architecture, MCP client (Gravity calls external tools)
v1.21	Real-Time	WebSocket hub, live updates on work package changes, presence awareness (who is viewing what)
v1.22	Automation Engine	Rules engine (trigger/condition/action model), agent dispatch as action type, scheduled rules
v1.23	Reporting and Analytics	Grafana dashboards, burndown charts, cycle time metrics, agent cost attribution
v1.24	Webhooks and Notifications	Outbound webhooks (Slack, Discord, custom), email notifications, in-app notification center
v1.25	API Hardening	Rate limiting, cursor pagination, Valkey response caching, batch CRUD, delta sync protocol
v1.26	SPA Phase 1	React + TypeScript + shadcn/ui foundation, component library, authentication flow
v1.27	SPA Phase 2	Work package views (list, board, detail), real-time sync via WebSocket
v1.28	SPA Phase 3	Wiki editor, time tracking UI, admin panels
v1.29	SPA Phase 4	Full feature parity with templ/htmx UI, templ UI deprecated

Strategic Assessment

Where Gravity Stands (February 2026)

Gravity occupies a position that does not exist in the current market: a self-hosted, open-source PM platform with integrated AI agent dispatch and zero feature gating. This is not because the position is brilliant -- it is because the position is difficult to reach (requires building a PM from scratch) and the market has not demanded it yet (most teams are fine with cloud PM).

The Honest Competitive Position

Against Linear: Linear is better at everything except self-hosting and open source. Their agent integration is more mature, their UX is years ahead, their sync engine is battle-tested. Gravity cannot compete with Linear on features or polish. Gravity competes on: self-hosting, no vendor lock-in, event-driven architecture (not webhooks), zero feature gating, flat cost at scale.

Against Plane CE: Plane is a more mature PM with a real team, real users, and real funding. But Plane CE does not include AI agent features. Gravity ships all features in the open-source version. If Plane ever opens their AI features to CE, Gravity's differentiation narrows significantly.

Against OpenProject CE: OpenProject is a 15-year-old production PM. It has features Gravity will not have for years (Gantt charts, cost budgeting, Scrum/Agile boards, plugins). But OpenProject has no AI agent integration and no event bus. Gravity's architecture is designed for a future OpenProject cannot easily retrofit.

The Strategic Bet

Gravity is betting that:

AI agents will become standard team members in project management within 12-18 months. Every PM will need agent-as-assignee, agent cost tracking, and agent orchestration.
Event-driven architecture is the correct foundation for agent integration. Webhooks are insufficient for reliable, replayable, transactionally consistent agent dispatch.
Self-hosted AI agent orchestration will be demanded by enterprises that cannot send project data to cloud PM providers.
Go + NATS + PostgreSQL is the correct infrastructure stack for a self-hosted PM that needs to be operated by a small team without dedicated DevOps.

If these bets are correct, Gravity's architecture is positioned to capture a market segment that does not yet exist. If they are wrong, Gravity is a well-architected hobby project.

What Must Happen for This To Work

v1.19.1 must ship (security, error handling, test coverage). The current codebase is not trustworthy for any deployment beyond development.
v1.20 must replace shell-out dispatch with SDK integration. The claude -p approach is a prototype, not a production feature.
At least one external user must deploy and provide feedback before v1.22. Single-developer validation is insufficient.
Agent-as-assignee data model must land before a competitor ships it. This is the feature that makes the PM-native event source actually useful.
The MCP server must adopt the official SDK. Hand-rolled JSON-RPC will fall behind the specification.

The Bottom Line

Gravity is an architecturally sound prototype that addresses a real market gap. It is not production-ready. It is not competitive with established PM tools on core features. Its value proposition is entirely forward-looking: when AI agents become standard project participants, the platform built event-first for that world will have a structural advantage over platforms that bolt it on.

Whether Gravity is that platform depends entirely on execution velocity over the next 90 days.

Last updated: 2026-02-22 | Gravity v1.19.0 | Author: Internal analysis with codebase verification