Core concepts

Kera is built from a small set of primitives. The app you click and the MCP surface your agents call are two faces of the same model — anything a person can do, an agent can do, and every action lands in the same audited history.

One model, two interfaces

There is no "AI mode" bolted onto Kera. The web app and the 150+ MCP tools operate on the same objects, enforce the same permissions, and write to the same audit trail. A ticket created by a teammate in the UI and one created by an agent over MCP are indistinguishable afterwards — same fields, same history, same rules.

This is the property everything else depends on: to give an agent a new capability, you don't build an integration — the capability is already there, because the agent and the human share one boundary.

The object model

Workspace
The top-level container. Holds members, groups, settings, and everything below. Identity and permissions are always derived from the workspace, never from a request parameter.
Project
A named container with a short key (e.g. KERA) that prefixes ticket IDs. Each project has a workflow and its own tickets.
Ticket
The unit of work. Typed (epic, story, task, bug, service request), with a state, assignee, priority, labels, relations, and attachments. The markdown body lives in git; Postgres holds the structured metadata and a search index.
Ticket type & workflow
Types carry different required fields; the workflow is the set of states and the transitions between them (e.g. open → in_progress → in_review → done).
Relations
Directed links between tickets — blocks, blocked_by, relates, duplicates. Together they form the dependency graph.
Cycles
Time-boxed iterations (sprints) that group tickets, with velocity and throughput metrics.
Milestones, initiatives, releases
Higher-level planning that spans projects — group work toward a date, a theme, or a shipped version.
Documents
Markdown documents, git-backed with full revision history, alongside your tickets.
Comments
Discussion on tickets and documents.
Groups
Named sets of members. Groups aren't just assignment buckets — they gate read and write access to tickets and documents (group-based access control).
Service desk
An intake surface: portal requests become tickets, routed by rules, tracked against SLA policies.
Widgets & dashboards
Your views over the data — ticket lists, charts, activity feeds, progress and completion metrics, arranged on a dashboard.
Audit trail
Every action, by every actor — user, admin, agent, or system — timestamped and queryable. The ground truth behind any status question.

Two principles worth remembering

  • Git-backed content is yours. Ticket and document bodies are plain text in git. Postgres stores only the derived index. You can export a complete, point-in-time snapshot at any moment.
  • Same model, two interfaces. The UI and the MCP surface never diverge. Learn the objects once and you understand both how your team works and how your agents work.

Next