DEV Community: SharpHaw

The row that replaces nothing: how SharpOS connects a client's accounts without owning them

SharpHaw — Mon, 07 Sep 2026 08:00:28 +0000

Open r/PPC or r/GoogleAnalytics on any given week and the same fight is running: an agency that "refuses to provide access" to the Google Ads account, a business owner who discovered the agency "took billing ownership of the account, even though I never gave permission", and the calm reply underneath from someone who has seen it too often — the business should own the account and the agency should sit inside it as a manager. Every client already has the accounts. The only real question is who holds them.

In part 1 of this series I called Integrations the row on our replacement ledger that replaces nothing. This is that row, paid in full: what SharpOS connects to, why it deliberately owns none of it, how the connection layer is built, and the five providers it cannot listen to. If you build anything multi-tenant that has to act inside a customer's accounts, the owning-nothing part is the bit worth stealing.

TL;DR: SharpOS connects a client's Google, Cal.com, Resend, WhatsApp, Facebook, ElevenLabs and model accounts so automations and agents can act through them. The accounts stay the client's, the tokens sit with a broker keyed to the client's organisation, and the workspace stores one row that says "connected, as whom".

Why "replaces everything" is the wrong promise for this row

The all-in-one pitch usually ends with a login count: one place for calendar, mail, messaging, forms, the lot. For most rows on our ledger that promise is honest, because the thing being replaced is a tool the engagement uses internally. Nobody outside the engagement cares whether the weekly queue lives in Trello or in Boards.

Calendars, mail delivery, WhatsApp numbers and model accounts are different. They are shared with the rest of the client's business, they carry the client's history, and in the Google cases they are the accounts the client will fight an agency over. A workspace that "replaces" them has either rebuilt Google Calendar badly or quietly moved the client's accounts under its own name. The first is a waste. The second is the hostage situation the r/PPC threads describe, with better UI.

So row 12 says connect, and it means it. The client keeps paying Google, Cal.com, Resend, Meta, ElevenLabs, OpenAI or OpenRouter. SharpOS gets a grant to act, scoped to one organisation, revocable from a card, and no more. Connect is a grant. Replace is a custody transfer.

What Integrations does instead

Integrations is one page in the hub, gated on the Integrations feature flag and on the manager role. Viewers and editors never see it. A manager connects a provider from a card grid: OAuth providers go through a hosted consent screen and come back to the same page; key-based providers (Resend, ElevenLabs, OpenAI, OpenRouter) take the key in a dialog. Once a provider is active, its actions and any triggers it has become available to three consumers at once: the Automations canvas, the REST API, and the MCP server agents use.

Today the grid holds Google Calendar, Google Sheets, Google Search Console, Google Analytics, Google Ads, Google Maps, Reddit, Hashnode, Dev.to, Resend, Facebook Pages, WhatsApp, ElevenLabs and Cal.com, plus the four social providers that predate the shared catalogue (Instagram, X, LinkedIn, GitHub), plus an AI providers card for OpenAI and OpenRouter keys, and the org's own SharpOS API and MCP credentials. Meta Ads has its own read-only grant and belongs to the Ads surface, so I'll leave it there.

You can walk through the page as a fictional client here: showcase → Integrations. Nothing you click leaves the browser. The feature page is at sharphaw.digital/features/integrations.

How it works

A broker holds the tokens, keyed to the organisation. Provider connections run through Composio as the credential broker. It custodies the OAuth tokens and API keys, and every connected account is keyed to exactly one organisation. SharpOS never stores a provider's OAuth token; it stores a connection record: which provider, which organisation, its status (connecting, active, invalid or revoked), and the account it runs as, so the card can show who it acts as. When an automation node runs, the backend loads the organisation's active connection and executes the provider action as that organisation, so there is no path from one org's workflow to another org's calendar.

The one exception is the AI providers card. OpenAI and OpenRouter keys are stored in SharpOS, encrypted, because the backend runs inference itself and a broker that proxies actions cannot proxy a streaming chat. Status reads expose a yes/no and an account label; the raw key never leaves the backend.

Bad keys never persist. Pasting an API key triggers one real call against the provider. If it fails, the broker account is deleted and the save is refused, so a wrong key cannot sit there marked active for a week.

Triggers are connection-scoped, and some providers have none. Google Calendar triggers are subscribed at connect time and delivered to one signed webhook. Cal.com offers no triggers through the broker, so the connection mints an unguessable address and a signing secret, registers a single Cal webhook carrying all four booking events, and retries after 1, 5 and 30 minutes if registration fails. The connection stays active throughout; a flaky registration should never take the action nodes down with it. Every inbound delivery is verified, matched against an active connection before any event fires, and deduplicated for 30 days. A "calendar event created → create calendar event" workflow cannot ping-pong itself, because created ids are remembered and their echoes dropped.

Agents get strict inputs. The REST and MCP surfaces for these providers use strict schemas: a misspelled field from an agent caller is rejected outright, never silently dropped. A DEV post this month told the story of an agent that "posted successfully. To the wrong account." The connection model above is our answer to the first half; strict inputs are the answer to the second.

What it doesn't do

Five providers cannot be listened to. Reddit, Search Console, Google Analytics, Google Ads and Google Maps expose no usable trigger, so "when X happens" is built the other way round: a schedule drives the query node and downstream steps branch on the result. Google Sheets has triggers in theory, but each one needs a spreadsheet id at subscription time, which a connect-time subscription cannot supply.

Google Ads has no reporting here, and no proxy escape hatch either. X and LinkedIn are text-only through the broker. Google Analytics reports go through a request proxy because the toolkit only covers the admin API. Connect, disconnect and provider selection are hub operations, on purpose; there is no REST endpoint that connects a client's Google account on their behalf.

And there is no marketplace. Twenty-odd providers, chosen because a SharpHaw engagement needs them, sitting on a broker that is a platform prerequisite. The fair objection is that I've moved the dependency rather than removed it, and that's true: if the broker vanished tomorrow, every connection would need re-consenting through whatever replaced it. The client's accounts, though, would be exactly where they were, and that is the property I care about. If your business needs three hundred connectors and a directory to browse, keep a general iPaaS. This layer exists so a client's automations and agents can act inside the accounts the client already owns, and it stops where that job stops.

Where it sits in the SharpHaw service

Integrations is the plumbing under AI Automations: a booking lands in Cal.com, a workflow reads the calendar, an email goes out through the client's Resend domain, a WhatsApp template confirms it. The client sees all of it in their own workspace, as every SharpHaw subscription includes SharpOS. What they never see is a request to hand over an account.

The question I'd put to anyone building the same layer: where do you draw the line between what your product should connect to and what it should absorb, and has a customer ever disagreed with you about which side something belonged on?

This is part of SharpOS, surface by surface. Part 1, the ledger and the decision behind it: We replaced a 12-tool client stack with one workspace we built.

We built a support widget with no human handoff. Here's why that's the honest version.

SharpHaw — Sun, 06 Sep 2026 14:00:26 +0000

Every agency has put a chat bubble on a client's site and then watched what happens to it. The client is a six-person firm. Nobody is assigned to the inbox. A visitor types "do you do Saturday appointments?" at 21:40, gets "an agent will be with you shortly", and leaves. On Monday somebody notices the queue.

That is the scene I kept coming back to when we built Support, the chat widget inside SharpOS. This series walks our workspace one surface at a time; this part is about the row on our ledger that stands in for Intercom and Zendesk, and about the feature we deliberately left out.

TL;DR: Support answers from a knowledge base the client controls, cites what it used, and says plainly when it can't help. There is no human handoff, on purpose.

What a helpdesk is for, and where it strains

Intercom and Zendesk are built around a team: seats, queues, assignment, a shared inbox across email, chat and social. If you have people whose job is answering, that shape is right. An AI layer deflects the repetitive questions and the humans take the rest.

The businesses we work with have no "rest". The owner is the support team, and the owner is also the sales team, the operations team and the person who signs the invoices. Give them a shared inbox and the bubble on their site becomes a promise the business can't keep. The handoff is the feature everyone lists first and nobody staffs.

I want to be precise about that: it's a statement about a buyer, not about the tools. A team with an inbox rota should keep its helpdesk.

What Support does instead

Support is a chat bubble the client embeds on any site with one script tag. Visitors ask, an assistant answers from the organisation's knowledge base, and every reply cites the entries it used. When the knowledge base can't back an answer, the assistant doesn't improvise; it shows a fallback message the client wrote, with their WhatsApp, email or phone appended. The unanswered question is filed as a suggestion in the hub, where it becomes a knowledge entry in one click. Conversations land in a read-only inbox in the workspace with an AI title, a summary and the visitor's mood. Clients without a site to embed on get a hosted help page instead, and the widget ships its UI in seven European locales while the assistant replies in whatever language the visitor writes.

The knowledge base is one table: authored Q&A, plus one row per item a connected source contributes. Sources can be a Page, a URL, or a Board column. That last one matters for us — a client's Blog board, Published column, becomes part of what the assistant knows, one document per card, kept in sync as cards are edited, moved or archived.

You can poke at the inbox in the showcase workspace, fixtures only, nothing leaves your browser. The feature page has the walkthrough.

Inside the organisation it follows the rules every SharpOS surface follows. The Support feature flag is off by default and enforced server-side. Editors read the inbox, managers configure the assistant. Once the Analytics flag is on too, Analytics gains a Support tab, read from daily rollups rather than by scanning conversations.

How it works

The install is the boring part, and boring is the point: one script tag on the client's site, carrying the widget's id, and the bubble is live.

The script mounts the chat in a frame served from our domain, so the widget's styles never collide with the host page's, and the host page opens no live connection until the visitor actually opens the chat. The script also gives the host page a small set of controls, open the widget, send a message, say who the visitor is, listen for a reply, and it only accepts those commands from the page that embedded it, and only posts visitor text back to that same page.

Two thresholds decide what the assistant is allowed to say. Each published Q&A is indexed twice: once as the question alone, so an exact question scores near 100%, and once as the full Q&A context. A match at or above the answer threshold (70% by default) grounds the reply. A best match below the capture threshold (60% by default) triggers the fallback and records the question as a suggestion for the knowledge base. Between the two it falls back quietly. The two dials are set per organisation, and the pair is ordered by construction, so no score can both answer and file a gap.

The part I'd defend hardest is the read-side check. A Page or a Board card can be archived, made internal, or deleted after it was embedded, and the search index is a derived copy that none of those paths write to. So before any source match can ground a public reply, the live page, board, column and card are re-checked, and a match that can't be proven serveable is dropped, including when the check itself fails. The widget degrades to the fallback rather than answering from a copy it can't verify.

The rest is the guardrails an unstaffed bubble needs. Visitor sessions are bound to the site that embedded the widget with a short-lived token and a domain allow-list. A visitor gets 8 messages a minute and 200 a conversation. An optional daily budget swaps every model call for a "high demand" message when it runs out. It all runs on the client's own OpenAI or OpenRouter key, held in their organisation, and the inbox shows an estimated cost per conversation. We don't sit between the client and their model bill.

What it doesn't do

It won't hand a conversation to a person. There is no agent seat, no queue, no "someone will be with you". If a customer's question needs judgement (a refund, a dispute, a change to an account), the assistant's job is to say so and give the contact channel, and the client's job is to answer that email the way they would have anyway.

It isn't a multichannel inbox; email, social DMs and phone don't flow into it. And it won't answer outside the knowledge base, which means an empty knowledge base produces a polite bot that mostly says "get in touch". That's correct behaviour until the base is filled, and we fill it from the Pages and Boards the engagement already produces.

If you have a support team, or your product generates conversations that genuinely need a human in the loop, keep Zendesk or Intercom. This row of the ledger is for the business that never had a support team and shouldn't pretend to.

Where it sits in the service

Support ships as part of SharpHaw's AI Automations work: the knowledge base is built from the client's own pages and boards, automations react to events such as conversation started and visitor identified, and captured questions feed back into the content we write next. It's included in the SharpOS workspace every subscription runs in.

The question I'd like answered

If you've shipped an AI-only support surface, where did you draw the "I can't help with that" line, and did your visitors respect it? I'm especially curious whether anyone has numbers on abandonment after a fallback message versus after a queue.

This is part of SharpOS, surface by surface. Part 1, on the whole ledger: We replaced a 12-tool client stack with one workspace we built.

Your client's Zap stopped running and nobody noticed. We built Automations around that failure.

SharpHaw — Sun, 06 Sep 2026 08:00:26 +0000

There's a thread on r/zapier that every agency person recognises on sight. One Zap per client, about thirty clients, and the Zaps have started not running. No error. The poster is doing manual data transfers for ten of the thirty. Further down someone asks the real question: "how do you catch a client's Zap that silently stops running? No error — just quiet."

I run SharpHaw, a small agency in Lisbon, and I built SharpOS, the workspace we run every client engagement in. Automations is row 9 of its replacement ledger, the row that stands in for Zapier and n8n. This post is about what it does, how it's built, and the part of that row we deliberately didn't try to replace.

TL;DR: inside a client engagement the trigger that matters is a card moving on a board, and the failure that matters is one somebody reads. We built the engine on the workspace's own event bus and made a failed run something the hub shows you, then accepted a much shorter connector list as the price.

What Zapier and n8n are for, and where they strain

Both are general-purpose integration platforms: a trigger in one app, an action in another, thousands of connectors in between. That is exactly the right shape when your events live in other people's systems. A Stripe payment, a Typeform response, a row in a sheet. If that's your problem, you already have the right tool, and nothing below argues otherwise.

The strain shows up when the thing you're automating is the engagement itself. The events that matter in our work are workspace events: a card moved to Approved, a brief page created, a form on the client's site submitted, an audit finding opened, a support conversation left unanswered. To automate those from outside you first have to export them, which means a webhook per event type and a mapping layer that drifts every time a field is renamed. And when it breaks, it breaks in a tool the client has never logged into. Both platforms can alert on a failed run if you wire that up; the question is who receives the alert and whether they read it. In practice the first person to notice is the client, weeks later, asking why the follow-up email never came.

What Automations does instead

Automations is a workflow canvas inside the org: trigger nodes, optional filter and branch nodes, action nodes. The triggers are the hub's own events (boards, customers, pages, forms, audits, studio, support), plus GitHub, Google Calendar and Cal.com events, inbound webhooks, and schedules. Actions create or update cards, customers, pages and studio frames, send email, call an HTTP endpoint, publish to Instagram, X and LinkedIn, and act through whatever the organisation has connected under Integrations. Data moves between steps with a {{variable}} templates, and a node's output is also addressable by its name, so a request named "Webhook Call" exposes the previous node's status downstream.

It's org-scoped and role-gated like everything else in the workspace: the feature flag is off by default, building and enabling is owner, manager or platform admin, and any member can read run history. A workflow runs as a named user and every action node re-checks that user's permissions at execution time, so a workflow cannot do something its author couldn't. You can click around a fixture-only version at showcase/vell/automations; the feature page with the walkthrough is at sharphaw.digital/features/automations.

One owned example: this series ships through it. When a card on our Dev.to board is approved, the board's own automation publishes the card body through the connected DEV account and writes the live URL back onto the card. Nobody pastes anything.

How it works

Three decisions carry most of the weight.

The engine listens to the hub itself, and listening is cheap. Every change in the hub — a card moved, a form submitted, a customer created — is checked against a small table of what the organisation's workflows actually subscribe to. If nothing subscribes, nothing is written. If something does, an event is recorded and one run is queued per matching workflow; each run walks the graph from the trigger, fills in the variables, records a step per node and follows the edges. Filters stop a path, branches choose one.

That subscription table earned its keep on schedules. The per-minute tick used to load every workflow with a schedule trigger and evaluate its timing in code: 386 documents and 222 KB per tick, 1,440 ticks a day, almost always to fire nothing. Copying each workflow's schedule onto its subscription row, in the same write that saves the workflow so the copy can't drift, turned the tick into a prefilter.

Every run is a record, and a failed run has read state. Each run stores its trigger payload and one step per node, with a redacted input and the raw output, so the run detail shows exactly what became the next node's variables. Runs can be replayed. A failed run is marked as read the first time a member opens it, and until then it sits in the hub home's Needs attention list, one click from the run detail. First read wins: once anyone on the team has seen it, the organisation has. That is the design answer to the r/zapier question. The Zap that quietly stops is invisible because nothing owns the failure; here the failure is a row on the same screen the client opens.

Webhooks are boring on purpose. An inbound webhook trigger gets an unguessable address and a signing secret that is hashed on the server and shown once. Only diagnostic headers are kept; authorisation headers, cookies and API keys are stripped at ingest and never become variables or run history. The node's panel shows the last real payload received and a copy-as-cURL button, which is most of what you actually need when wiring a third party in.

Agents build workflows over the same API a person uses through the canvas: create the workflow, validate it (a trigger present, known node types, valid configuration, connected edges, no cycles), then enable it. A form's answers arrive as variables named after the field labels, and a blank optional answer renders empty rather than leaving a stray placeholder in your payload.

What it doesn't do

The connector list is short. Automations acts through the providers an organisation has connected under Integrations, which today is around fifteen, against the thousands a general platform offers. If your trigger lives in a system we don't connect, or your action does, Zapier or n8n is the right tool and we'll happily point a webhook at it in both directions.

Runs and events are pruned after 30 days, so it is an operational log, not an archive. There's no marketplace of prebuilt templates; a workflow starts from the canvas or from the API. And the engine assumes the workspace is where the work happens, which is the bet the whole product makes. If your team's real board lives elsewhere, the triggers you care about won't be here.

Who should keep n8n: anyone who wants to own the engine itself, run it on their own box, and connect anything. That's a legitimate preference and it isn't the one we made.

Where it sits in the service

Automations is the surface behind SharpHaw's AI Automations work: we map a client's recurring time sinks and wire the ones that belong to the engagement here, next to the boards and forms that produce the events. It ships inside SharpOS with every subscription.

A question for the people running client automations

If you've run automations for clients, where did the silent failures actually surface: in the tool, in your inbox, or in the client's complaint? I'd like to know whether the read-state approach would have caught yours.

This is part of SharpOS, surface by surface. Part 1, the whole ledger and the row we couldn't replace: We replaced a 12-tool client stack with one workspace we built.

We put a link-in-bio page inside every client workspace. Here's the click pipeline behind it.

SharpHaw — Sat, 05 Sep 2026 14:00:27 +0000

Open the Instagram profile of almost any small business we talk to and the bio link goes to a page on somebody else's account. Often the freelancer who set it up two years ago. The colours are close to the brand, the buttons point at the right places, and when the owner asks where the clicks come from, the honest answer is a screenshot from a dashboard they can't log into. One marketer on r/marketing put the whole problem in a sentence: "I am trying to get more information about the people clicking on my linktree link, such as where does the people clicking are coming from."

I'm Gabriel, founder of SharpHaw, and this is the second post in a series about SharpOS, the workspace we run every client engagement in. Part one covered the replacement ledger as a whole. This one takes row 11: Spotlight, our link-in-bio surface, and mostly the click pipeline underneath it, because that's the part I'd want to read about.

TL;DR: the link page is the smallest public thing a client owns and the first thing they hand to a third party. Spotlight puts it inside the client's workspace, on their Brand Kit by default, with clicks counted next to everything else we ship for them.

What a link-in-bio page is for, and where a hosted one strains

Instagram won't linkify a URL in a post, so "link in bio" became the one door out of the app, and Linktree and Bio.link built good products around that door. Unlimited links, a theme picker, an analytics tab, a URL you can put on a business card. For a creator running their own account, that's the right tool and I'd tell them to keep it.

Inside a client engagement the same page strains in three places. The brand gets retyped into a theme editor, so the moment the client's colours change, the link page quietly doesn't. The analytics live in an account that belongs to whoever created it, which is why "where do the clicks come from" turns into a screenshot. And the page is the client's front door on the one channel they post to every day, held in a tool nobody in the business owns. A comment on r/SaaS about Linktree's own position says the quiet part: "you don't collect a ton of data about your customers and worst of all it's entirely dependent on Meta's platform." For the vendor that's a business risk. For the client it's their door.

What Spotlight does instead

Spotlight gives each organisation one or more public, branded link pages at a short public address, built in the hub with three tabs: Edit, Design, Share. Links can be grouped, given a subtitle and a real brand icon, dragged into order. Nothing exotic. The part that matters is what happens when nobody opens the Design tab.

Unset means inherit. A colour, font or corner radius left empty resolves from the organisation's Brand Kit before it falls back to a default, so a page nobody styled is already on-brand, and a Brand Kit edit reaches every such page with no per-page action. Even the logo inherits: a page with none of its own serves the kit's wordmark, the dark-surface mark when the page runs dark. Where the kit's colour names don't match the heuristic, a slot can be bound to a named kit entry and it stays read-only until unbound.

Every page has its own analytics view (clicks, views, unique visitors, click-through rate, a ranked list per link), and the organisation's Analytics page has a Spotlight tab that rolls all pages up with source, device, country and campaign breakdowns. Access follows the standard model: internal pages are agency-only, client pages are visible to every member, only platform admins flip that, and click analytics are editor-and-above whichever the page is. The whole surface sits behind a feature flag, off by default. If the organisation has saved tracking codes under Integrations, the hosted page carries them with a consent prompt. You can open a real one here: a fixture workspace's Spotlight surface, browser-only, nothing persisted. The feature page is at sharphaw.digital/features/spotlight.

How the click tracking works

The public page renders each button as a real link that opens in a new tab. There is no redirect in the path. One view is recorded per session when the page loads, and each button press sends a tiny click beacon to our own origin, addressed by the page's permanent token rather than its slug — so a client can rename the slug and every deployed embed keeps reporting. Navigation proceeds whether or not the beacon lands.

Attribution keys off a stable per-link id, never the link's position in the list, so reordering or editing a link never corrupts its history. Each event is one append-only record; nothing is read and then updated, so a burst of clicks produces no contention. Every five minutes the raw events are rolled up into a daily table, clicks, views and unique visitors per link and per page, which is what the dashboard reads. Raw events are pruned after 90 days; the daily aggregates are kept forever.

The decision I'd defend hardest is keeping two identities apart. Abuse control uses an opaque key derived from the edge's trusted network address, and only that key is accepted for rate limiting. Analytics uses a random visitor id generated in the browser and hashed together with the page id before it is stored. Rotating the visitor id cannot allocate more limiter rows, and the page-wide capacity check runs before any per-client row exists, so an attacker who has filled a page cannot grow persistent state by inventing ids. Country and device come from the edge's own request headers, which the browser can't forge; referrer and UTM come from the browser and are reduced to a bare host or an allow-listed value and never rendered as a link. No IP, no coordinates, no raw user agent is stored. Breakdowns count views rather than clicks, because the clicks after an arrival came from the same place and counting them again would flatter the source.

A click also emits an event into Automations, and the whole page model is reachable over REST and MCP, where going live is deliberately two switches: publish the status, then enable the page.

What it doesn't do

Say the limits before anyone else has to. The page lives on our domain today, not the client's. There is no storefront, no payment block, no email capture, no marketplace of add-ons. Unique visitors are a sum of daily uniques and are marketing-grade, not billing-grade; a determined actor can inflate the visitor count even though the ceilings bound what gets accepted. And there is no tracked redirect yet, so a click from a no-JS context or an email prefetcher isn't counted. If a client sells through their bio link, or needs the page on their own domain this quarter, Linktree or Bio.link is still the right answer and I'll say so on the call.

Where it sits in the service

Spotlight belongs to the Content Engine side of what SharpHaw does: the bio link is where the content we ship for a client gets distributed on the channel they post to daily, and now the clicks land in the same workspace as the posts. The service is described at sharphaw.com/services/content-engine, and SharpOS itself, the workspace all of this runs in, at sharphaw.com/sharp-os.

One question for anyone who has built click tracking on a public page: how do you keep the identity you rate-limit on separate from the identity you count on, and did you end up with a redirect anyway?

This is part of the SharpOS, surface by surface series. Part 1, on the whole ledger: We replaced a 12-tool client stack with one workspace we built. Here's the row we couldn't.

Route Gemini 3.8 Flash by risk, not model rank

SharpHaw — Sat, 05 Sep 2026 14:00:25 +0000

Gemini 3.8 Flash is capable enough that “Flash for easy work, Pro for hard work” is no longer a useful router.

Google positions the GA model for long-horizon software engineering, autonomous agents, and complex enterprise workflows. The practical question is no longer whether Flash can attempt the task. It is whether your workflow can detect and contain a bad attempt.

Here is the risk router I would start with.

Define the job before the model

Give every agent step four properties:

reversible: can you undo the result cheaply?
externalSideEffect: does the next tool call affect a customer, money, permissions, public content, or production data?
acceptanceTest: can software check the output?
verificationMinutes: how much human time does a clean result still need? The model comes after those answers.

The thresholds are placeholders. Measure them on your own queue. The shape of the decision is the useful part.

Put Flash on the bounded path

Gemini 3.8 Flash is a good default when the output stays a draft or has a cheap mechanical check.

Examples:

extract fields and validate them against a schema;
classify records into an existing taxonomy;
draft code behind tests and branch protection;
summarise documents with source links;
rewrite copy inside explicit length and vocabulary rules;
compare records and flag exceptions without changing them. These jobs are not necessarily simple. They are bounded.

Google’s model page lists a 1,048,576-token input limit, a 65,536-token output limit, function calling, structured output, code execution, and search grounding. That makes the model a credible worker inside a tool-rich system. None of those features decides whether the next tool call is safe.

Escalate before the side effect

Do not wait for a low-confidence answer after the action has happened.

Put the gate immediately before the workflow sends, publishes, pays, deletes, grants access, or mutates production state.

The larger model receives the failed attempt and the validation errors. That is better than a blind retry with more tokens. A person receives only work whose consequences justify the interruption.

Keep thinking level inside the route

Gemini 3.8 Flash supports low, medium, and high thinking. Medium is the default, and minimal is unsupported.

Treat thinking level as effort within a route:

low for latency-sensitive, tightly specified work;
medium for the normal bounded path;
high for a difficult step that still remains safe to attempt with Flash. Thinking level does not replace authorisation, validation, idempotency, or rollback. Those are workflow properties.

Measure cost per accepted result

Input and output token prices are useful, but they miss the expensive part of many agent systems: review and repair.

Track these four numbers for each route:

first-pass acceptance rate;
human review minutes;
escalation rate;
escaped-error rate. Then calculate total cost per accepted result.

If Flash halves inference spend and doubles review time, the route got more expensive. If it handles most of the queue and cleanly escalates the exceptions, the architecture is working.

Start with the exception list

Gemini 3.8 Flash raises the baseline for fast, cost-efficient agents. Use that advantage on work your system can observe.

Write the stop conditions before the prompt:

missing or contradictory input;
policy conflict;
validation failure;
high-impact side effect;
repeated uncertainty;
verification cost above your threshold. The model choice will keep changing. A router built around reversibility, blast radius, ambiguity, and verification cost will survive the next release.

What condition in your current agent should trigger escalation but does not yet?

We built a Canva-shaped editor into our client workspace. Here's what we left out on purpose.

SharpHaw — Sat, 05 Sep 2026 08:00:26 +0000

Every agency I know has the same handoff problem with social templates, and it's written up on Reddit. A designer builds the system in Figma. The client wants to edit their own posts, so the designer rebuilds it in Canva, "essentially tracing over a screenshot of that design on a Canva canvas", as one of them put it on r/FigmaDesign. A few weeks later the posts come back with the wrong green and a stretched logo, and the designer is asked why the brand looks off.

I'm Gabriel, founder of SharpHaw, a small agency in Lisbon, and I built SharpOS, the workspace we run every client engagement in. Studio is the design surface inside it. This is what it does, how it's built, and exactly what we left out, since part 1 of this series already admitted that Studio is not Figma.

TL;DR: Studio treats a template as data with named slots. People fill slots in the canvas editor; agents fill them over the API; the result publishes to Instagram from the same workspace the client reads. Everything Figma and Canva do beyond that, we deliberately didn't rebuild.

What Figma and Canva are for, and where the handoff breaks

Figma is where a design system gets made: components and constraints, the precision a brand identity needs. Canva is where a non-designer edits a finished layout without breaking it, which is why a designer on r/graphic_design calls it "the most client-accessible / design-friendly templating tool I've found for clients".

Both are good at their job. The break is between them, and it's structural. The template lives in a tool the client rents, on an account the agency either shares or loses access to. The posts it produces live somewhere else again, in a scheduler or a camera roll. The brand system that should govern the template lives in a PDF. Even where those tools expose automation, nothing in that chain knows a card on the client's content board exists, so nothing can fill the template when the card is approved. A human re-traces it and uploads the result somewhere else. Every week.

What Studio does instead

Studio is SharpOS's canvas editor for social content. Three objects: templates (org-scoped, reusable layouts sized per platform), projects (containers for a set of posts), and frames (the slides inside a project, each optionally seeded from a template). Members with edit rights design in a three-panel editor; export gives you PNG or JPG, or MP4 when a frame carries video; publish sends a frame to the organisation's connected Instagram account without leaving the hub.

The part that changes the workflow is the slot. Any text, icon, image or video element in a template can carry a slot name. The API then treats the template as a form: create a frame from a template, pass slots for text and icons and image slots or video slots for media, and Studio writes the layers. That is how covers on our own editorial boards get made — a template called "Dev.to Thumbnail" carries one image slot, and the publishing pipeline fills it. No editor session, no designer.

Access follows the workspace. Studio sits behind the Studio feature flag, checked server-side on every call. Templates and projects carry client or internal visibility; org members read and edit client-visible assets and cannot see internal ones. The client's team member opening the workspace sees the same project the agency is working on, not an export of it.

How it works

The canvas is a real drawing surface, and the entire design of a frame is one document: a tree of text, rectangles, circles, images, video, icons, SVGs and groups. Groups are flex containers, so a caption block reflows when the headline grows. Any element can be marked as a slot ("headline", "cover", "logo"), and a slot is what makes a template fillable: the API fills the slots and leaves the rest of the design alone.

The decision that cost the most, and the one I'd warn anyone building a canvas editor about: every visual property exists in four rendering contexts — the interactive frame, the read-only preview of the other frames, the headless export, and the thumbnail. Video adds a fifth. Add a corner-smoothing control to the properties panel and forget the export path, and the post looks right in the editor and wrong on Instagram. So every effect has exactly one place where it is resolved, colour opacity goes through one shared step everywhere, and the table that lists those contexts sits near the top of the feature's own documentation.

Two more decisions came from production rather than planning. A project's frame count used to be computed by reading every frame in the organisation; each frame's design is roughly 20 KB, one org reached 817 frames, and the listing crossed the database's per-request read limit and failed on every call until we stored the count on the project itself. And publish renders now record which renderer produced them, because a server-side fallback rasteriser once produced a drifted carousel cover that passed every freshness check and reached Instagram while the project itself looked correct. We retired that renderer version outright; every frame carrying it reads as stale and re-renders on its next open.

Video export runs in the browser, encoding H.264 and mixing the audio down locally. A frame that is exactly one full-bleed video publishes the original file with no render at all, which is most Reels.

What Studio doesn't do

This is the section I'd want from anyone who built instead of bought.

Studio is not a design system tool. There are no components with variants, no shared styles, no plugins, no vector pen, no prototyping. If the brand identity is being designed, it's being designed in Figma, and it should be. Studio starts once the system exists.

It is not Canva either. There is no stock library, no thousands of starter templates, no consumer polish. Our templates are ours, per client, built once. The editor is desktop-only. The four-context rule means every new visual feature costs four implementations, so the property list grows slowly and on purpose.

And a template made in Studio is data with slots. That is its whole advantage and its whole limit: a machine can fill it, which means a person has to design it to be fillable. A template that can't be filled by a machine is a mockup with a nicer name.

Where it sits in the service

Studio is how the Content Engine ships visuals: a board card gets approved, a frame gets filled, a post goes out, and the client sees all three steps in their workspace. The feature page at sharphaw.digital/features/studio has a recorded walkthrough of the editor.

A question for people who've built on Konva

If you've built or maintained a canvas editor, what did you cut first when you realised every property had to exist in every render path? I'm curious whether anyone found a way around the four-times rule rather than a way to enforce it.

This is part of SharpOS, surface by surface. Part 1, the tool stack we replaced and the row we couldn't: https://dev.to/sharphaw/we-replaced-a-12-tool-client-stack-with-one-workspace-we-built-heres-the-row-we-couldnt-pg3

We replaced the brand guidelines PDF with tokens the client's forms, link page and chat widget inherit

SharpHaw — Fri, 04 Sep 2026 14:00:27 +0000

The brand guidelines PDF has a specific moment of death, and it is the handover. A designer on r/graphic_design asked it plainly: "this is my first time I'm creating a brand guidelines document for my client. I don't know how to handover it to the client." Whatever the answer was, the file went into a Drive folder, and six months later the client's contact form was one purple, their link-in-bio was another, and the chat widget on the site still ran the vendor's default blue.

I run SharpHaw, a small agency in Lisbon, and I'm the engineer behind SharpOS, the workspace we run every client engagement in. Brand Kit is the row on our replacement ledger that stands in for the PDF. This is what it does, how it's built, and where it is deliberately smaller than the tools designers already use.

TL;DR: the PDF describes the brand; the kit is what the client's forms, link page and support widget read at runtime. We kept it small on purpose.

What the PDF is for, and where it breaks

A brand guide is an argument. It says why the mark looks the way it does, what the photography should feel like, which CMYK values stand in for a hex that print can't reproduce. None of that belongs in a database, and I'm not proposing to put it there.

The problem is narrower. Nothing executes a PDF. A veteran on r/branding put it better than I can: "If your identity isn't embedded in the tools your team actually uses, it will drift. Within six months, your social media will look different from your site." For an agency the drift is worse, because the touchpoints that go wrong are the ones we ship. A form we built, a link page we built, a chat widget we embedded. If those don't read the brand from somewhere, we are the drift.

What Brand Kit does instead

Every organisation in SharpOS gets one Brand Kit at the Brand page of the hub. It holds a theme scope (light, dark or both), up to six fixed logo slots plus custom named images, semantic colour variables with a light and a dark value each, named type styles with a Google Fonts family, a base radius with a derived sm/md/lg/xl scale, an icon pack, and a list of markdown documents for the parts of the brand that are prose. Every section is optional. An empty kit shows a teaching empty state, and Preview only renders what has content.

Any org member can read it; owners, managers and editors change it inline in Edit mode, with a debounced autosave. The Brand Kit feature flag is on by default and enforced on the backend as well as the route. It is org configuration rather than content, so it carries no client/internal visibility toggle.

Two things make it more than a settings page. First, the export dialog copies the tokens as CSS variables (the root variables plus the dark override), JSON, or a Tailwind theme-extension snippet, so a client's own site can consume the same values we do. Second, and this is the part I care about, downstream surfaces inherit the kit as their default theme. Every form, every Spotlight link page and the Support widget resolve the kit's colours, fonts, radius and theme mode through one shared resolver. Change the primary colour once and every form that hasn't overridden it restyles.

You can open a populated kit in the browser-only showcase, no login: Palazzo Marzano's brand kit. The feature page is at sharphaw.digital/features/brand-kit.

How it works

Three decisions carried most of the weight.

Inheritance is a name heuristic, and I say so. Colour entries in the kit carry no semantic role. A colour has a name, a light value and optionally a dark value, and nothing more, because forcing a role taxonomy onto a designer's palette produces a form nobody fills in. So the surfaces that inherit the kit map by name: a colour called "primary" or "brand" becomes the accent, "background" or "surface" becomes the background, "foreground" or "text" becomes the text colour. The honest consequence is that renaming a colour can change how a form looks. We documented that rather than hiding it, because the alternative is a schema nobody fills in.

Theme scope is destructive, on every write path. Switching a kit from "both" to light-only clears the dark values instead of hiding them. That rule is enforced on the server on every save, whether the change comes from the hub or the API, so a kit can't be left inconsistent by either. Because it deletes data, narrowing the scope opens a confirm dialog that names exactly what goes ("the dark value from 4 colours, and the logo — alternative image"), computed from the current draft.

The kit never auto-renders a logo. A logo slot can point at a Media Center asset or at a Studio frame. A frame-backed slot stores a reference, so editing the frame in Studio updates the brand asset, but the image shown is the frame's last published render, and that render can be older than the frame. Server-side rendering has known font and wrap drift against the editor. Silently healing a brand asset with a slightly wrong render would be worse than an honest badge, because the thing being altered is the client's identity. So every slot reports whether its render is ready, stale, missing or a video, and a stale one shows an amber "Out of date" with an "Open in Studio" link. The share image only uses a frame-backed image while its render is fresh, because social platforms cache a share image hard.

Adding frame-backed slots needed no migration: a slot value is either an asset or a frame reference, the two are told apart by shape, and every pre-existing kit kept working unchanged.

The export is deliberately boring. A kit in "both" scope with a colour, a radius and a heading style exports as a flat set of CSS variables: the colour, the radius and its derived small, medium, large and extra-large steps, the corner smoothing, the heading font and size, plus a dark override that only carries the values that differ. The dark override appears only in "both" scope, and only when at least one colour has a dark value. A light-only or dark-only kit exports a single flat set, because there is nothing to switch between.

What it doesn't do

Brand Kit is smaller than a design-system tool, and it should stay that way. There are no components, no Figma or Storybook sync, no versioned releases of the system. It is not an asset library either; Media Center is, and the kit only references it. The brand documents are a markdown textarea with a preview tab, not the collaborative block editor the rest of SharpOS uses. Studio and Pages don't consume the tokens yet. The squircle preview relies on the CSS corner shape property, which only recent browsers render, though the smoothing value always exports as a corner smoothing token for whatever tool reads it next.

If you run a design team with a component library and a governance process, keep it. Brand Kit is for the business that has one brand, six surfaces we run for it, and nobody whose job is to keep them aligned. The kit is the alignment.

Where it sits in the service

We use it inside Conversion-First Websites: the site's tokens live in the kit, the forms on the site inherit them, and the client can read the same kit in SharpOS at any hour. That is the whole pitch, and it fits in one sentence.

The question I have for you

Where does your brand actually live today, and what reads it? If the honest answer is "a PDF, and people", I'd like to hear which touchpoint drifted first.

This is part of the series SharpOS, surface by surface. Part 1 is the ledger itself: We replaced a 12-tool client stack with one workspace we built.

A production checklist for Framer and Webflow templates

SharpHaw — Fri, 04 Sep 2026 14:00:25 +0000

I do not reject website templates. I reject ambiguous production ownership.

A good Framer or Webflow template can remove a large amount of layout work. It may already have responsive sections, a CMS structure, interactions and a coherent visual system. That is useful engineering leverage.

It is not a production contract.

Before I call a template-based marketing site ready, I want six things defined and tested. They are the difference between "the pages render" and "the website can do its job without a developer watching it".

1. Give every page a conversion contract

Start with one object per important page:

type ConversionContract = { path: `/${string}` audience: string promise: string primaryAction: "submit_form" | "book_call" | "start_checkout" | "visit_pricing" successDestination: string owner: string } const contactPage: ConversionContract = { path: "/contact", audience: "owner-operator comparing website partners", promise: "leave with a clear recommendation for the site", primaryAction: "book_call", successDestination: "calendar confirmation and CRM lead", owner: "growth", }

This is deliberately boring. It stops a page from collecting three competing CTAs because the template shipped with buttons in three places.

The contract also gives QA something testable. If the primary action is book_call, a click on a social icon is not evidence that the page works.

2. Replace the content model, not only the nouns

Swapping a template's company name, colours and screenshots is the easy pass. The deeper pass asks whether the section order matches the buyer's decision.

For each section, write down:

the question it answers
the evidence it uses
the next objection it creates
whether the next section pays that objection off Delete sections that have no job. Add the missing decision before worrying about visual variety.

A template is a useful hypothesis about how a generic buyer might read. Your finished site needs a specific argument for your buyer.

3. Name events before adding analytics

"Install analytics" is not an acceptance criterion. Define the event vocabulary first.

type MarketingEvent = | { name: "cta_clicked"; page: string; cta: string } | { name: "form_started"; form: string } | { name: "form_submitted"; form: string; leadId: string } | { name: "booking_confirmed"; bookingId: string }

Then verify that each event fires once, carries the expected properties and survives consent rules, redirects and client-side navigation.

Both platforms can support serious optimisation. Framer has built-in experiments around defined conversion events, and Webflow publishes a workflow built around blockers, hypotheses, QA and a testing roadmap. The tools exist. The implementation still needs a measurement model and an owner.

4. Test the handoff after submit

The successful form state is the middle of the flow, not the end.

My minimum test matrix includes:

valid submission -> CRM record exists -> owner notified -> confirmation shown duplicate email -> defined merge or duplicate behaviour provider timeout -> recoverable error -> no silent loss spam submission -> filtered -> conversion reporting protected mobile submit -> keyboard closes -> state remains visible

Run the tests in production after launch as well as in preview. A polished form that posts to the wrong destination is a conversion bug, even if every pixel is correct.

5. Write the ownership and rollback note

Before handoff, record:

who owns the domain and platform account
who can publish
where form data goes
where analytics lives
which third-party components or licences the site uses
how to restore the last working version
who receives the first alert when something fails Webflow's paid marketplace templates use a single-use licence, and template-specific support belongs to the creator unless the problem is in Webflow itself. Framer's own template checklist says its recommendations are optional and templates are not manually reviewed. Those are manageable constraints. They simply belong in the operating record.

6. Schedule the first post-launch change

Do not end the project plan with "launch".

End it with the first evidence review. Pick a date, name the decision-maker and state what will be inspected:

type FirstReview = { date: string inspect: Array<"traffic" | "cta_rate" | "form_quality" | "sales_objections"> decisionOwner: string allowedOutcome: "change" | "hold" | "instrumentation_fix" }

Low traffic may make an A/B test inconclusive. That does not remove the need to review the site. It changes the evidence you use. Form quality, sales-call objections, support questions and failed handoffs can still produce useful work.

The template is not the shortcut you should fear

The dangerous shortcut is leaving the decisions unnamed.

Use a template when it fits. Modify it until the content model belongs to the business. Define the conversion contract. Instrument the actions. Test the handoff. Record ownership. Put the first review on the calendar.

At that point the template has done its job: it saved implementation time without becoming the operating model.

Sources: Framer A/B testing, Framer template practices, Webflow template overview, Webflow template licence.

How every file in our client workspace lands in one library (and where Drive still wins)

SharpHaw — Fri, 04 Sep 2026 08:00:25 +0000

Every client engagement starts with the same email. "Could you send us your logo, a few photos and the brand PDF?" What comes back is a Drive link, a Dropbox request, two WhatsApp images and a PowerPoint. Three months later the site's hero image lives in Drive, the Instagram crop lives in Dropbox, and the approved logo is in a chat thread nobody can search.

I run SharpHaw, a small agency in Lisbon, and I built SharpOS, the workspace we run every client in. This series takes our replacement ledger one row at a time. This row: Google Drive and Dropbox, and the surface that stands in for them, Media Center.

TL;DR: a shared folder stores files. A client workspace needs a library that every other surface writes into and reads from, so an image uploaded anywhere is the same asset everywhere. That is the whole design, and it has real limits.

What a shared drive is for, and where it strains

Drive and Dropbox are good at the job they were built for: a folder tree, sync to a laptop, a share link, permissions per person. For a company's own documents that is exactly right, and I'm not going to pretend an agency workspace does any of that better.

Where it strains is the client relationship, and the r/agency threads on this are blunt. "We frequently run into issues with clients not having Gmail accounts or Gmail connected work emails and having them set that up is annoying." Another agency creates a folder per client, shares it, then asks the subreddit how to take it back when the engagement ends. The failure is structural. The folder belongs to someone's account, the link belongs to whoever was emailed it, and the files end up wherever the last tool needed them. Nothing about a folder knows that the file inside it is the cover of a page, the logo in a brand kit, or the image a form respondent uploaded ten minutes ago.

What Media Center does instead

Media Center is the organisation's shared file library: images, documents, video and other approved files, uploaded once, organised into nested folders, searched, and reused across the product. Every org member can browse it. Uploads, moves, renames and deletion sit behind the asset-edit right, checked at the route and again in the client. The Media Center feature flag gates the route and the save and delete mutations server-side, like every other surface in the workspace.

The part that matters is what else writes into it. A cover set on a page or a board card, an image property on a card, a media field on a public form, an image pushed over the API: all of them register in the same library. Form uploads land in an auto-created a Forms folder named after the form folder keyed to the form id, so renaming the form doesn't orphan the folder. REST callers get folder and asset CRUD, moves and both upload paths, through the same Media Center flag and the same capability the hub checks. There is one asset pool per organisation, and every surface is a door into it.

You can open one and click around: the Media Center inside a showcase workspace. It runs on fixtures in your browser, no account, nothing persisted.

How it works

Storage follows the same pattern everywhere in SharpOS: the browser asks for an upload slot, sends the bytes straight to storage, then records the asset — its name, type, size, folder, tags and what kind of preview it gets — as a small record that points at the stored file rather than containing it. Two decisions I'd defend in a review.

Validation reads storage, never the caller. File types are filtered before upload for the user's benefit, then enforced again when the asset record is created, from what storage itself reports about the file, never from a type or size the client claimed. That one backstop is shared by the hub, by form uploads from strangers, and by the API, so there is no path where a caller's claim about a file is trusted.

Two-step uploads because of a proxy cap. Production API traffic goes through a proxy that caps request bodies at 20 MB, while an organisation's upload limit reaches 250 MB. So the API mirrors the hub's flow: ask for an upload slot, send the bytes directly, then register the asset. A one-call route that takes a public URL or an inline payload exists for anything under the cap. Deleting a folder over the API requires an explicit "recursive" flag when the folder isn't empty; the hub can afford a confirm dialog, an API caller cannot.

Browsing is paged at 48 records, and a page never resolves preview URLs up front. Previews are requested separately for the files a new page added, deduplicated, and refused above 60 at a time. The upload bar reports real bytes sent rather than an animation, because I wanted the percentage to mean something.

What it doesn't do

Media Center is shallower than Drive or Dropbox, on purpose, and you should know where.

There is no desktop sync client and no offline copy. There is no version history on a file; you upload the new one. There is no share-with-an-outsider feature: access is membership, a public form's respondent can upload in, but nobody outside the organisation browses the library. There is no document editing in place; the collaborative writing surface in SharpOS is Pages, and Media Center is where Pages puts the images. Deleting an asset that a page or card still uses as its cover leaves a stale reference the cover UI treats as empty, rather than blocking the delete.

If the job is the client's own company files, keep the drive. If the job is the files the engagement produces and consumes, the library is where they should already be.

Where it sits in the service

Every SharpHaw subscription runs inside SharpOS, and Media Center is the asset pool under the Content Engine: the photos, exports and brand files a week's content draws on sit next to the pages and boards that use them. The SharpOS overview shows the rest of the workspace, and the feature page has the walkthrough.

The question I'd ask you

If you've moved a team off a shared drive into something purpose-built, what did people quietly keep using the drive for? That list is usually the honest spec for what the replacement still lacks.

This is part of SharpOS, surface by surface. Part 1 covers the whole ledger and the row we couldn't replace: https://dev.to/sharphaw/we-replaced-a-12-tool-client-stack-with-one-workspace-we-built-heres-the-row-we-couldnt-pg3

How I made AI disclosure part of the chatbot shell

SharpHaw — Thu, 03 Sep 2026 14:00:28 +0000

If your chatbot’s AI disclosure lives in the welcome message, an ordinary copy edit can remove it.

That was the failure mode I wanted to eliminate in SharpOS Support. The result is simple: the product shell always renders an identity line before the conversation starts.

AI assistant · May make mistakes.

The organisation can configure the assistant name, welcome copy, knowledge and fallback contact. It cannot disable that line.

This article is about the implementation model, not legal advice. Article 50 of the EU AI Act has applied since 2 August 2026, and the European Commission says providers of systems designed for direct two-way interaction should ensure that people are informed they are interacting with AI from the start of the first interaction.

Here is the architecture I use around that requirement.

1. Render identity outside generated content

The assistant should not be responsible for disclosing that it is an assistant.

Generated content can drift. Instructions change. Welcome messages are localised. A retrieval failure can produce a response before the intended introduction. The disclosure belongs in deterministic UI.

Conceptually, the shell owns it:

function AssistantIdentity() { return ( <p aria-label="AI assistant. May make mistakes."> <a href="/ai-transparency">AI assistant</a> <span aria-hidden="true"> · </span> <span>May make mistakes.</span> </p> ) }

The real implementation details will differ. The important boundaries are stable:

the text appears before the first response;
it is not supplied by the model;
organisation-level configuration cannot clear it;
the link opens a fuller transparency explanation;
the accessible name still makes sense without the visual separator. Do not rely on a bot avatar or a clever product name to make AI “obvious”. Explicit text is cheaper to test.

2. Treat the knowledge base as an allow-list

The disclosure says what the system is. It does not constrain what the system says.

SharpOS Support grounds answers in approved knowledge. I think of that knowledge as an allow-list of claims rather than a folder of helpful documents.

A source should have:

type KnowledgeSource = { id: string status: "draft" | "approved" | "retired" ownerId: string reviewedAt: string content: string }

Only approved, current sources should enter retrieval. A retired pricing page should not remain available because embeddings were generated once and forgotten.

The model instruction is equally important: answer from the supplied evidence, identify missing evidence and avoid filling the gap with general knowledge when the question is about this business.

3. Make uncertainty a typed product state

Do not model fallback as another friendly paragraph the model might choose to write.

The orchestration layer should be able to produce a result that is not an answer:

type SupportResult = | { type: "answer"; text: string; sourceIds: string[] } | { type: "fallback"; reason: "missing_knowledge" | "low_confidence" } | { type: "blocked"; reason: "policy" | "sensitive_request" }

The UI then renders organisation-approved fallback copy and a real contact route.

In SharpOS Support, this is intentionally not a fake live-agent handoff. If the business provides an email, WhatsApp number or phone route, the fallback points there. If no person is waiting in a support queue, the interface should not imply that one is.

Typed states also make the behaviour measurable. You can count fallbacks without attempting to infer them later from prose.

4. Store enough context for review, not everything forever

Conversation review is part of the control loop.

Store the outcome type, source IDs, timestamps and the minimum conversation content needed for the business to diagnose gaps. Apply access controls and a retention policy appropriate to the personal data customers may put into a chat box.

The review queue should answer:

Which questions repeatedly fell back?
Which approved source produced the answer?
Which visitor suggestions recur?
Did the contact exit work?
Which knowledge source needs an owner or review date? This is more actionable than a total-message chart.

5. Test the shell, not only the model

Model evaluations will not catch a disclosure hidden below a mobile viewport.

I add deterministic product tests around the interaction:

test("shows AI identity before the first message", async ({ page }) => { await page.goto("/support") await expect(page.getByText("AI assistant")).toBeVisible() await expect(page.getByText("May make mistakes.")).toBeVisible() await expect(page.locator("[data-message]")).toHaveCount(0) })

Then test the whole path:

Open as a first-time visitor.
Check the disclosure on desktop, mobile and zoomed layouts.
Ask an answerable question and verify the source boundary.
Ask an unsupported question and verify the typed fallback.
Follow the contact route.
Confirm the conversation appears in the review surface. ## The design rule

Product transparency should be deterministic. Model behaviour should be bounded. Failure should be explicit. Review should produce a change.

That is the difference between adding disclaimer copy and making disclosure part of the system.

We didn't replace Google Analytics. We put a page in front of it that says what needs attention.

SharpHaw — Thu, 03 Sep 2026 14:00:26 +0000

Every agency I know has built the client a dashboard at least once. A Looker Studio page with the GA4 connector, a logo in the corner, twelve tiles, a date picker. The client opens it twice. The first time they say it looks great. The second time they email to ask what it means, and from then on the monthly update goes back to being a call.

I run SharpHaw, a small agency in Lisbon, and SharpOS is the workspace we run every client engagement in. Analytics is the surface I have rewritten the most, because the first version was exactly that dashboard. This post is what it became, what it deliberately doesn't do, and why it sits on top of PostHog instead of trying to be one.

TL;DR: SharpOS Analytics is a reading surface, not a collector. PostHog underneath, a thresholded "Needs attention" list on top, and every signal is one sentence with a link to the surface that fixes it.

What GA4 and Looker are for, and where they strain

Google Analytics 4 is a collector with a reporting UI attached. It is very good at the first job, and the people on r/GoogleAnalytics have been saying the second part out loud for a while: "They have shifted from an analytics tool to a data collection tool with GA4. It is an amazing shift for power users, but does not seem to sit well with regular users." Looker, and Looker Studio with it, is a builder: hand it sources and it will let you compose any chart you can imagine. Both are excellent tools for someone whose job is analytics.

The founder paying an agency is not that person. Their question is narrower and harder: what moved this month, is anything wrong, and what did you do about it. A blank canvas answers none of that, so someone at the agency fills the canvas with tiles, and the result is what our audience research keeps quoting back at us: "reports full of jargon, green arrows, and charts that don't really mean anything." One Hacker News commenter called it the "any data is good data" trap — big, beautiful dashboards full of irrelevant, misleading data. I have built that dashboard. It ships fast and it gets read never.

What Analytics does instead

One page, four tabs, one shared date range that lives in the URL.

Overview is the tab a founder opens. It carries a row of cross-source signals (visitors, Spotlight clicks, support conversations, satisfaction, uptime), one "Audience over time" chart with all three sources on a shared axis, and Needs attention: a deterministic, thresholded list where each row is one checkable sentence and a link to the surface that resolves it. The thresholds are code, covered by tests, rather than a judgement call made per client. A status page that isn't configured shows up there as a sentence, because an absent tile is indistinguishable from a healthy one that scrolled off. When nothing crosses a threshold, the list says "Nothing needs attention this period", which is an answer in itself.

Website is the organisation's own PostHog project, read in depth: five KPI cards with deltas against the previous equal-length period, visitors over time with the last period as a dashed line, traffic sources, top pages, devices, countries, entry and exit pages, UTM sources, week-one retention, a goal-conversion readout and a live "right now" tile. SharpOS installs no tracking and warehouses nothing for this tab. A platform admin connects the client's existing PostHog project once, the credentials stay server-side, and members read the result.

Spotlight and Support report on data SharpOS collects itself: link-page views, clicks and CTR by source, country and device; conversations by outcome, resolution and fallback rates, reply speed, unanswered questions with a link to triage them, and the assistant's token spend priced with the inbox's own table.

Roles do the rest. Any readable member sees Overview and Website; the two agency-internal tabs are editor and above; the whole surface sits behind the Analytics feature flag, and Spotlight and Support additionally need their own. You can open a fixture version of it here: Analytics in the SharpOS showcase — browser-only, no account, nothing you type leaves the tab.

How it works

Three decisions carry the surface.

Each tab loads only its own source. Website, Spotlight and Support are separate tabs with separate loading states, and opening one never fetches the others. That matters because the Website tab's PostHog request is metered upstream: someone who opened Analytics to read the Support inbox should not spend a website query. Once a tab has loaded, its data stays warm while you move between tabs, and the website dashboard is cached per date window, so switching back is instant.

Spotlight and Support numbers come from daily rollups. Both tabs read pre-aggregated daily rows rather than scanning the underlying conversations or click events, because no capped scan answers a ninety-day question honestly, and the busiest organisations are exactly the ones a scan would under-report. The counters are updated by the same operations that record each event, and if a timestamp is unusable the counter is skipped rather than the event being lost. A reporting number is never allowed to be the reason a visitor's message fails to save.

A hidden tab is not enforcement. The tab strip is derived from what your role and your organisation's flags allow, but every tab re-runs its own check when opened, and every query re-asserts the flag and the permission on the server. A direct URL is never looser than the strip.

One more, because it is the kind of thing that bites later: the conversion event a client chooses is the only piece of caller-supplied text that reaches the website analytics query, so it is checked against a strict allow-list of characters and refused if it doesn't match. It is never quietly "cleaned" into a different name. A goal either matches exactly or the query doesn't run.

There is also a pin control on every KPI card. A member can pin up to six metrics to the hub home, and the pinned tile and the card it came from read one definition — because the first version had two, and home was quietly drawing a clicks line under a CTR label.

What it doesn't do

It is not a BI tool. There is no report builder, no data blending, no SQL explorer, no custom dimensions. If the client's team has an analyst who lives in Looker, they should keep Looker. Analytics is read-only, and the Website tab is only as good as the PostHog project behind it. Anything beyond the core visitor and session metrics is best-effort: a failed optional query hides its own block rather than the page, which is the honest way to say "we couldn't get that this time".

Historical Support numbers rebuilt from the raw tables are approximations; everything written since the rollups shipped is exact. And a viewer sees two tabs rather than four, by design.

Where it sits in the service

Analytics is where the Ads Management and Conversion-First Websites work gets read: the board that moved a card this week is one click from the number the card was meant to move. It ships inside every SharpOS workspace, and the feature page is at sharphaw.digital/features/analytics.

The question I keep coming back to

If you report to clients, what is the one number they actually ask about, and does your dashboard lead with it or bury it under eleven others?

Part of the series SharpOS, surface by surface. Part 1, the replacement ledger and the row we couldn't replace: We replaced a 12-tool client stack with one workspace we built.

We replaced the audit PDF with a work queue. Lighthouse stayed.

SharpHaw — Thu, 03 Sep 2026 08:00:26 +0000

Every agency client has received one: the audit. Forty pages, a score on the cover, a table of issues sorted by severity, exported from a crawler on a Tuesday and emailed with a line like "let's walk through this on the call". Three weeks later somebody asks whether the duplicate title tags were fixed, and the honest answer is that nobody opened the PDF again after the call.

I run SharpHaw, a small agency in Lisbon, and I built SharpOS, the workspace our client engagements run in. Audits is the row on our replacement ledger that sits opposite Semrush and Lighthouse. This post is about what that row does, what it deliberately doesn't do, and why the audit surface in our own product has no "Run audit" button.

TL;DR: the crawler was never the bottleneck. The PDF was. Audits in SharpOS is where findings live, get rechecked against the live site, and get closed. It does not crawl.

What Semrush and Lighthouse are for, and where they strain

A crawler-backed SEO suite does one thing well: it walks a site and produces findings. Missing descriptions, thin pages, broken canonicals, duplicated titles, a health score you can track over time. Lighthouse does the other half: a lab run against one URL that tells you where the performance, accessibility and SEO basics stand, with the specific audit that failed. Both are good tools — I still run PageSpeed against pages I'm about to ship.

The strain shows the moment the findings have to reach a client. The crawler lives in the agency's account, so the output has to be exported, and an export is a snapshot. Then the snapshot has to be explained, so it becomes a call. Then the call ends and the findings have nowhere to sit except inbox history. The threads on r/SEO say it plainly: one owner pushing back on an 18-hour audit because "the report is repetitive", another warning that autogenerated audits "frequently miss" what matters. Both are complaints about the document rather than the crawl. Our own playbook has the same line about the agency model in general: audits and strategy documents become PDFs that vanish after the first week.

What Audits does instead

Audits is the workspace where a site's findings live. Each site a client cares about is an audit target inside their organisation. A run against that target holds the crawled pages, the findings (scored across eleven categories), the artefacts, and a short structured verdict, and the org's members open it the way they open a board. If you want to see what that looks like without an account, the fixture-only showcase runs the real components in your browser: open a target here.

The part that changes the client's experience is what happens to a finding after it exists. A finding has a status, so it can be set to done. A finding can become a page or a board card in one action, which is how "fix the duplicate titles on the service pages" turns into a card on the same weekly board the client already watches. And a finding can be rechecked against the live site: a recheck that passes deletes the finding, a recheck that fails keeps it and says so. The audit stops being a document you re-read and becomes a queue you drain. The feature page puts it in five words: the audit that doesn't disappear.

Visibility and roles apply the way they do everywhere else in the workspace. A target is client or internal; internal ones are platform-admin only and don't appear in listings at all. The Audits feature flag gates the routes, the navigation and every backend access path, so an org without the feature never reaches a handler.

How it works

SharpOS doesn't crawl. That is the decision the surface is built around, and it's why there is no "Run audit" button. Crawling and analysis happen in an agent outside the product (ours runs from a repo-local skill with a set of deep-dive lanes: conversion path, message quality, answer-engine readiness, performance, accessibility, trust), and the agent pushes results in through the integration API: create the target, open a run marked as agent-sourced, push the pages, push the findings, push the insights, finalise. Scoring is computed on the server at finalise, from the evidence that was ingested. Every write requires the platform admin key; an organisation's own API token can read client-visible findings and cannot create a single one.

That split keeps two things honest. A long crawl never has to fit inside a backend function's runtime. And the workspace is the source of truth for what a site looked like, rather than a mirror of whatever the crawler's account remembers.

Ingest reports what was persisted, not what was sent. A page-level finding whose URL matches no ingested page is dropped, and the dropped URLs are listed back to the agent, so a push that only partly landed is visible immediately. Ingested pages must belong to the target's host. And a new run replaces the previous run's evidence: pages, findings, artefacts and blobs go, and only the older run's score and finding count stay as history. Storage doesn't grow without bound, and the workspace always shows the current state of the site rather than a stack of stale ones.

Lighthouse stayed, in one specific place. Rechecking a Largest Contentful Paint, Cumulative Layout Shift or Interaction to Next Paint finding triggers a fresh PageSpeed probe and evaluates the result against the Core Web Vitals thresholds. Pass, and the finding is deleted. Fail, and it stays, marked as rechecked and failed. If the probe can't be captured at all, the finding is kept — a recheck may only delete evidence when it has evidence. Only finding types SharpOS can genuinely re-evaluate on the live site can be rechecked; anything else is refused up front instead of being silently resolved.

What it doesn't do

Audits does not out-crawl a dedicated SEO suite, and it isn't trying to. There is no keyword research, no backlink index, no rank tracking, no competitor visibility graph. If your work depends on those, keep the suite. Lighthouse itself isn't replaced either; it's called during rechecks, and PageSpeed remains the lab measurement we trust for that.

There is also no crawl cockpit. You can't start a run, watch a progress bar, or stop one from the hub, because the run isn't happening there. An hourly sweep marks runs that stopped reporting progress as failed, and the workspace's History tab is where a failed run gets reviewed. For a team that wants a button and a spinner, this is the wrong shape.

Where it sits in the SharpHaw service

Audits is the first thing that happens on a conversion-first website engagement and the thing that keeps happening after: the run finds the problems, the board carries them to done, the next run confirms the fix. It ships inside SharpOS with every subscription.

The question

The audit-as-PDF shape has survived a long time, and I suspect it's because a document feels like something you handed over, while a queue feels like an admission that the work isn't finished. If you've moved audit findings into a tracked system (tickets, cards, anything with a status), what happened to the findings nobody would have fixed from the PDF? And what did you lose by dropping the document?

This is part of SharpOS, surface by surface. Part 1, with the full replacement ledger: We replaced a 12-tool client stack with one workspace we built.