Extract the dashboard into the actionagent gem, with feature parity

[TonsOfFun]

Why

Two things happened here, in order.

First, the dashboard engine that shipped in this gem had model classes for agents, runs, versions, templates, sandboxes and recordings — but no migrations to back them. They were dead code. The real implementations lived in the activeagents platform, had drifted from these copies, and were the only ones anyone ran. So the engine became the product: mount it and you get what activeagents.ai gives you.

Then it became clear that could not live inside activeagent.

The dashboard is now its own gem

activeagent   2546.1 KB → 134.5 KB    163 files, zero dashboard
actionagent                 360.0 KB    85 files, zero JSX sources

The framework gem shrank 95%. Size was the visible problem; the dependency graph was the real one:

• activeagent deliberately declares actionpack/actionview/activesupport/activemodel/activejob and not activerecord. The engine's models inherit ActiveRecord::Base.
• lib/active_agent.rb required the engine unconditionally in every Rails app, appending eight app/* paths to every host's autoload and eager-load paths. An API-only app on --skip-active-record would have crashed in production on an undeclared dependency — and CI could not have caught it, because the dummy app sets eager_load = false and requires active_record/railtie unconditionally.
• AgentExecutionService mixes in SolidAgent::HasContext, and solid_agent depends on activeagent. The framework could never declare a dependency its own dashboard code has. That's a cycle. There is no packaging of this code inside activeagent where the graph is true.

actionagent declares all three honestly. Rails puts data in Active* and the request/response layer in Action*, so the namespace follows the gem: ActiveAgent::Dashboard::Agent → ActionAgent::Agent, mounted as ActionAgent::Engine.

The engine now sits at a real gem root, so the find_root override it needed while buried under lib/ is gone.

What a mounted engine gets you

Agent builder, runs and versions. Conversations (contexts, messages, generations). Evaluations, scorecards and cost estimates. Templates, sandboxes, session recordings, provider and API keys. Your agents as an authenticated MCP server at <mount>/mcp. Plus the traces and metrics that were already here.

The React dashboard ships prebuilt in the gem — mounting it never asks the host to run a JavaScript build, or to have one. Inertia is gone; state arrives as a JSON data attribute.

Seams, not assumptions

Everything the platform's code reached for is configuration now, defaulting to what a single-user self-hosted install wants:

Seam	Unset means	The platform passes
table_name_prefix	active_agent_* tables	"" — its tables predate the engine
owned_by (per model)	nothing is owned	agents per user, keys per account
quota_checker / usage_recorder	unmetered	plan limits and run counters
provider_credentials_resolver	config/active_agent.yml	the account's own provider keys
agent_scope_resolver	the agents you own	every agent the account's members own
tenant_resolver	the owner itself	a user's account, since traces hang off accounts
sandbox_backends	in-memory only	Incus, Kubernetes, Cloud Run
execution_enabled	agents can run	—

current_user_resolver / current_account_resolver replace the *_method symbols, which could not work: the engine's controllers are their own base class, so a host app's current_user helper isn't on them. Configuring current_user_method = :current_user — the obvious thing to write — recursed forever.

Nothing breaks for existing installs

ActionAgent::Compatibility keeps ActiveAgent::Dashboard, ActiveAgent::TelemetryTrace and ActiveAgent::ProcessTelemetryTracesJob resolving through const_missing with a deprecation. That last one matters beyond tidiness — Active Job serializes the class name into the queue payload, so jobs enqueued before an upgrade are dequeued after it.

Runs on more than PostgreSQL

Every PostgreSQL-only query has a portable form and takes the fast path only when the adapter has it: COUNT(*) FILTER → SUM(CASE …), DISTINCT ON → a max-id pass, ILIKE → LOWER(…) LIKE, date_trunc → per-adapter bucketing, jsonb traversal → reading the column in Ruby. JSON columns are jsonb on PostgreSQL and json elsewhere. The whole suite runs against the SQLite dummy app.

Testing

• Engine suite: 42 runs, 0 failures, on SQLite
• Framework suite: 1264 runs, 0 failures — the 253 errors are the pre-existing missing-OPENAI_API_KEY ones, same count as main
• Both gems build; contents verified — no JSX sources or node_modules leaked
• Smoke-tested mounted in the platform against PostgreSQL: sign-in → dashboard renders with fingerprinted engine assets, props carry the mount path and agents, API/metrics/console/client routes respond, unknown /api/* 404s
• Added an eager-load test, which immediately caught MCPRecordingMiddleware in mcp_recording_middleware.rb — resolvable only in an app that had registered an mcp acronym

⚠️ Breaking

The server-rendered traces console moves from <mount>/traces to <mount>/console/traces. <mount>/traces is now the React traces view — same data, richer — so old links land somewhere sensible, but the ERB page is no longer there.

Review notes

• The engine's models are the platform's, so the diff reads as new files rather than edits to the drifted copies they replace.
• actionagent/app/assets/builds/* is build output, committed on purpose — that's what lets a host app skip the build. Sources are in actionagent/frontend/; node_modules is excluded from git and the gemspec.
• Benchmarks (the ragents harness) deliberately did not come along.
• Two CI fixes ride along: the dummy schema was regenerated against Rails 8.1 and pinned to Schema[8.1], which the older Rails in the API-gems matrix cannot load (back to [8.0]), and rubocop's array-bracket rule on the same file.

[Copilot]

Copilot wasn't able to review this pull request because it exceeds the maximum number of lines (20,000). Try reducing the number of changed lines and requesting a review from Copilot again.