FinishLine by Asymmetri
FinishLine
One place to run the studio, for people and their agents.
- Operations, Industry and Logistics
- AI, Agents & Data
- Application Development
01In short
FinishLine in short
Asymmetri's own delivery operating system: projects, QA, clients, chat and calendars in one secure app, where AI agents work as the person who sent them.
- Client
- Asymmetri (our own product)
- Domain
- Operations, Industry and Logistics
- Category
- Internal platform · Web app + AI agents
- Platforms
- Web app, Installable PWA, Client portal, MCP server
- Services
- Product design, Web development, AI agent engineering, Platform engineering
- Year
- 2026
- −66%Task read time
- 4×Faster server load
- ~3,650Permission assertions
- 33AI agent tools
02Context
The story of FinishLine
Challenge
A studio that ships for clients runs on a dozen tools: one for tasks, one for QA, chat somewhere else, calendars, leave and meeting notes in others, and clients asking for updates by email. Every hand-off between them loses context, and the newest teammates, AI agents, couldn't safely touch any of it. So we built our own.
Approach
FinishLine is Asymmetri's delivery operating system. Projects, tasks, boards, timelines and sprints sit next to multi-round QA, a client portal, realtime chat, Google Calendar, meeting notes, leave, learning and each person's plan for the day, with two-way Slack, GitHub and Linear sync for the work that lives elsewhere.
Every surface (the web app, the client portal, background jobs, inbound integrations and AI agents) goes through the same row-level security in Postgres across five roles. Claude, ChatGPT and Cursor connect through a hosted MCP server and act as the person who sent them, with the same permissions, notifications and audit trail.
Insight
Build one door for everyone. Then make the door fast.
We put every rule in one place, the database, so a person, a client, a cron job and an AI agent all meet the same permissions. That made the product safe by default. It also made speed a database problem, and that's exactly where we went to solve it.
2 hard problems
- P01Make an app that checks every permission on every row feel instant.How do you keep security in the database, five roles deep, and still open a project of 850 tasks before anyone notices the wait, on serverless infrastructure that goes to sleep?
- P02Let AI agents do real work, as exactly the person who sent them.How do you let Claude, ChatGPT or Cursor read and change projects, tasks and QA without opening a side door around the permissions, approvals and notifications the team relies on?
03Secure and instant
Hard problem 01 of 02
Make an app that checks every permission on every row feel instant.
How do you keep security in the database, five roles deep, and still open a project of 850 tasks before anyone notices the wait, on serverless infrastructure that goes to sleep?
A delivery tool is opened a hundred times a day. Every slow page is a small tax on the whole studio, and slow tools get abandoned for spreadsheets and side chats. But taking security out of the database to win speed would have meant every new surface, from client portal to AI agent, re-implementing the rules and one day getting them wrong.
Why it’s hard
- F.01Security costs timeA per-row permission check takes a fraction of a millisecond. Across 850 tasks and five roles, it adds up to most of the page.
- F.02Serverless forgetsFunctions that sleep wake up slowly. A cold start of two to four seconds lands on whoever happens to be first.
- F.03Live, but privateBoards and chat must update the instant something changes, without leaking a row to anyone who shouldn't see it.
- 01FrameFind the valuable decision, workflow or experience.
Measure before you guess.
We profiled where a page actually spent its time and found it wasn't where anyone expected. The home screen alone made about 1,450 project-access checks per load. Query planning cost more than some queries. Every page waited on a network round trip just to confirm who was logged in, and the first visitor after a quiet spell paid for the cold start.
- ~1,450 permission checks per home load
- Manager reading all tasks: 160 ms
- Cold starts of 2–4 s after idle
- 02DesignShape the interaction, context and control model.
Never trade security for speed. Change how it's evaluated.
The rule stayed: the database is the only security boundary. What changed was the shape of the work. Instead of asking 'can this person see this row?' 850 times, ask once 'which rows can this person see?' and let Postgres join against the answer. Verify sessions locally. Defer everything the user isn't waiting for. For realtime, send ids, not rows, and let each browser fetch what it's allowed to see.
- Set-based permission policies, computed once per query
- Local session verification instead of an auth call per loader
- Realtime broadcasts carry ids only, on private topics
- 03EngineerBuild the intelligence, agent and tool chain.
Shave every layer.
Permission policies were rewritten as hashed sets, hot functions pinned to generic plans, and read and write policies split so reads stop planning edit joins. Sessions are verified with signed tokens in the function itself. Heavy libraries load only when needed, the browser database client is lazy-loaded, and notifications are sent after the response returns. Boards and QA statuses update optimistically and roll back on failure.
- Database triggers send one small broadcast per change
- Notifications deferred until after the user's save returns
- 47 KB gzipped cut from every page's JavaScript
- 173 indexes, keyset pagination for long lists
- 04ProveEvaluate performance, safety and economics.
Faster, and provably just as strict.
Speed means nothing if it leaks. Every rewrite ran against a permission test suite that signs in as each role and asserts what it may and may not see: 1,666 checks for the task rewrite alone, and about 3,650 across the product. The lean home query was proven to return exactly what the full one did for seven roles. Timings are medians of repeated cold runs, not a lucky best case.
- Task read as a Manager: 160 ms → 55 ms
- Server load: 1.6 s → 0.4 s; 300-row render 783 ms → 503 ms
- Home planning 2–3× faster with generic plans
- 05OperateDeploy, observe and improve in the real workflow.
Keep it warm. Keep it honest.
A scheduled ping keeps the app warm so nobody waits for a cold start, at about 4% of the hosting free tier. Live updates stay well inside the realtime connection limit. When one bundling change broke production, it was rolled back the same day and redone the safe way, and the commit says so.
- Keep-warm ping every minute
- Realtime capped at 80 of 100 channels per connection
- A recorded rollback, then a safer fix
The answer · Secure and instant
Security stayed in the database. We made the database fast.
- −66%Task read time for a Manager
- 4×Faster server load
- −36%300-row list render
- 3,650Permission assertions in tests
04Agents as teammates
Hard problem 02 of 02
Let AI agents do real work, as exactly the person who sent them.
How do you let Claude, ChatGPT or Cursor read and change projects, tasks and QA without opening a side door around the permissions, approvals and notifications the team relies on?
Our team already worked with agents in their editors and chats. The work itself lived in FinishLine. Connecting the two would save hours a week, but an agent that can change a project is also an agent that can quietly skip QA, notify the wrong client or touch something its user can't.
Why it’s hard
- F.01A second front doorAn API built for agents drifts from the rules in the app. Every validation and notification has to be written twice and kept in step forever.
- F.02Borrowed trustAn agent acts on someone's behalf. Tokens have to be scoped, revocable, rotated and impossible to replay.
- F.03People stay in chargeThe team has to see what an agent did, admins have to be able to switch it off, and some decisions must stay human.
- 01FrameFind the valuable decision, workflow or experience.
Agents are teammates, not integrations.
We reframed the brief. The question wasn't 'what should the API expose?' It was 'what should a teammate who happens to be an agent be allowed to do?' The answer: whatever the person who sent it can do, nothing more, and in plain sight.
- Listed the jobs people already asked agents to do
- Set the rule: an agent is its user, never more
- Named what stays human-only, such as learning grades
- 02DesignShape the interaction, context and control model.
Same door as a human.
Agents don't get their own endpoints. A write from an agent builds the same request the web app would send and runs the app's own action, signed in as that person. Validation, permissions, notifications, Slack copies and emails are identical by construction. Each person chooses Off, Read, or Read and edit for their agents, admins can block individuals, and the company has a single switch.
- Agent writes run through the web app's own actions
- Per-person access: Off, Read, or Read and edit
- Deletes need explicit confirmation
- 03EngineerBuild the intelligence, agent and tool chain.
A hosted MCP server with its own OAuth.
FinishLine is its own OAuth 2.1 authorization server, with discovery, dynamic client registration, PKCE, revocation and rotating refresh tokens that detect replay. On approval it creates a real session for the user, stores it encrypted, and keeps only hashes of tokens. Thirty-three tools cover the studio: fifteen to read, fifteen to act, plus search, identity and a confirmed delete.
- OAuth 2.1 with PKCE and refresh-token replay detection
- Sessions encrypted with AES-256-GCM; tokens stored as hashes
- 33 tools, down from ~60 fine-grained ones in the first version
- 04ProveEvaluate performance, safety and economics.
The agent hits the same wall a person does.
Because agents go through the same door, the same permission suite covers them, with dedicated tests for agent access and live end-to-end tests where an agent reads and writes real records. Rules that must stay human, like learning results, are guarded in the database itself, so no prompt can talk its way past them.
- Agent access covered by the same row-level security tests
- Live end-to-end agent read and write tests
- Human-only results guarded in the database
- 05OperateDeploy, observe and improve in the real workflow.
Every agent action, in plain sight.
Each agent action is logged, and notifications say who sent it: 'via Claude'. Rate limits and a company-wide kill switch sit on top. The studio now plans its day, files tasks, updates QA and writes notes through agents, and the team built FinishLine's second version the same way, with AI-assisted engineering through most of its 674 commits.
- Audit log of every agent action
- Notifications marked 'via <agent>'
- Works with Claude, ChatGPT and Cursor
The answer · Agents as teammates
An agent in FinishLine is its user: same door, same rules, every action on the record.
- 33Agent tools over MCP
- 1Rule set for people and agents
- 3Agent clients supported
- 0Side doors around permissions
05Glimpse of the product
A glimpse of the product.
Tap a screen to enlarge
06FAQ
Questions about Asymmetri.
Yes. Asymmetri built a hosted Model Context Protocol (MCP) server for FinishLine, its own delivery platform, so Claude, ChatGPT and Cursor can read and act in it as the person who connected them. It includes a full OAuth 2.1 authorization server with PKCE and refresh-token replay detection, 33 tools, per-person access levels, an audit log and a company-wide kill switch. Agent writes run through the same actions as the web app, so permissions and notifications are identical.
Asymmetri keeps row-level security as the only security boundary and changes how it is evaluated. In FinishLine, per-row permission functions were replaced with set-based policies computed once per query, hot functions use generic plans, and read and write policies are split. A Manager's read of all tasks dropped from 160 ms to about 55 ms in testing, with about 3,650 permission assertions proving nothing became less strict.
Asymmetri measures first, then trims every layer. For FinishLine on Vercel that meant verifying sessions locally instead of calling the auth service on every page, lazy-loading heavy libraries, deferring notifications until after the response, and a keep-warm ping. Server load fell from about 1.6 s to 0.4 s in testing, and a 300-row list renders in 503 ms instead of 783 ms.
Yes. FinishLine syncs with Linear both ways using a three-way merge, an outbox and keyset catch-up so no update is lost or echoed; bridges client Slack channels; tracks GitHub pull requests and checks; and keeps Google Calendar current through push notifications that fold bursts of changes into a single sync, with a scheduled reconcile as a safety net.
Asymmetri builds with AI-assisted engineering and holds the output to the same bar as any code. FinishLine's second version was rebuilt in about five and a half weeks, with AI co-authoring most of its 674 commits, alongside about 2,460 unit tests and about 3,650 database permission assertions. The team also runs its own day through AI agents connected to FinishLine.
Asymmetri tests permissions in the database itself. FinishLine has 81 row-level security test files with about 3,650 assertions that sign in as each role (admin, manager, internal, external and client) inside a rolled-back transaction and check exactly what each may read, change or never see, including what AI agents can do on a person's behalf.
Asymmetri is a hard problems technology company. It engineers AI systems, agents and digital products for global brands, across four areas: intelligence, process, experience and scale. Asymmetri works through four practices: AI agentic systems and data, application development, technology consulting, and innovation and R&D.
Every Asymmetri engagement runs one loop with five stages. Frame: find the valuable decision, workflow or experience. Design: shape the interaction, context and control model. Engineer: build the intelligence, agent and tool chain. Prove: evaluate performance, safety and economics. Operate: deploy, observe and improve in the real workflow. The loop repeats, so each pass lands closer to the target. Asymmetri's case studies show each hard problem moving through it.
Send a short brief through asymmetri.in/contact-us or email hey@asymmetri.in: the problem, what's in the way and your timeline. No deck or RFP is needed. Asymmetri replies to set up a framing conversation, then proposes a prototype or pilot with scope, team, timeline and what success looks like.
07More work