{"id":9136,"date":"2026-11-10T04:52:51","date_gmt":"2026-11-10T04:52:51","guid":{"rendered":"https:\/\/www.skyalleys.com\/?p=9136"},"modified":"2026-11-10T04:52:56","modified_gmt":"2026-11-10T04:52:56","slug":"cognitive-work-architecture-open-source-ai-agent","status":"publish","type":"post","link":"https:\/\/www.skyalleys.com\/index.php\/cognitive-work-architecture\/cognitive-work-architecture-open-source-ai-agent\/","title":{"rendered":"Building an AI Agent That Knows Its Own Cost: Open-Sourcing the Cognitive Work Architecture"},"content":{"rendered":"\n
\"Abstract<\/figure>\n\n\n\n

Most AI agents are built to be impressive. This one was built to be accountable.<\/h2>\n\n\n\n

There’s a gap in the AI agent ecosystem that nobody talks about at conferences.<\/p>\n\n\n\n

Every tutorial shows you how to build an agent that works. Few show you how to build one that works within a budget<\/strong>, enforces its own behavioral rules in code<\/strong>, and degrades gracefully when something goes wrong<\/strong> instead of showing your visitors an error page.<\/p>\n\n\n\n

We’ve spent the past year building and deploying AI agents for enterprise clients. Along the way, we developed an internal framework we call the Cognitive Work Architecture (CWA)<\/strong>, a set of patterns for building agents that operate with the same governance, cost discipline, and accountability you’d expect from any production enterprise system.<\/p>\n\n\n\n

Today, we’re open-sourcing the first agent built on this architecture: the Site Sales Agent<\/strong>.<\/p>\n\n\n\n

Not a demo. Not a proof of concept. The actual production code running on our website, handling real conversations, tracking its own cost to six decimal places on every single request.<\/p>\n\n\n\n

GitHub:<\/strong> Cognitive-work-architecture\/sales-agent<\/a><\/p>\n\n\n\n

What the Site Sales Agent Actually Does<\/h2>\n\n\n\n

The agent sits on our website as a chat widget. When a visitor asks about our services, it responds with the depth and nuance of a senior sales advisor \u2014 not the enthusiasm of a chatbot desperately trying to book a meeting.<\/p>\n\n\n\n

Here’s what happens on every request:<\/p>\n\n\n\n

    \n
  1. The visitor’s message arrives with their conversation history<\/li>\n\n\n\n
  2. Cloudflare Turnstile verifies the request isn’t from a bot<\/li>\n\n\n\n
  3. The monthly budget is checked, if exhausted, a graceful fallback is served<\/li>\n\n\n\n
  4. The session prompt count is checked, if exceeded, a human handoff is offered<\/li>\n\n\n\n
  5. The model generates a response using cached site content<\/li>\n\n\n\n
  6. Five layers of output processing enforce behavioral rules<\/li>\n\n\n\n
  7. The actual token cost is calculated and accumulated against the monthly budget<\/li>\n\n\n\n
  8. The clean response is returned with optional booking CTA<\/li>\n<\/ol>\n\n\n\n

    Every step in that flow has a failure mode, and every failure mode has a handler. The visitor never sees an error.<\/p>\n\n\n\n

    The Three Pillars<\/h2>\n\n\n\n

    The architecture rests on three pillars that we believe every production AI agent needs:<\/p>\n\n\n\n

    1. Budget Governance<\/h3>\n\n\n\n

    2. Behavioral Guardrails<\/h3>\n\n\n\n

    3. Graceful Degradation<\/h3>\n\n\n\n

    Let’s look at each one.<\/p>\n\n\n\n

    Pillar 1: Budget Governance<\/h2>\n\n\n\n

    This is the pillar most agent builders skip entirely.<\/p>\n\n\n\n

    Here’s the typical AI agent cost management strategy: deploy the agent, hope the token costs stay reasonable, and find out what you actually spent when the invoice arrives 30 days later.<\/p>\n\n\n\n

    That’s not engineering. That’s gambling.<\/p>\n\n\n\n

    Per-Request Cost Tracking<\/h3>\n\n\n\n

    Our agent calculates the exact cost of every single request using the token counts from the model’s response metadata:<\/p>\n\n\n\n

    RATE_INPUT_CACHED = 0.15 \/ 1_000_000\nRATE_INPUT_STD    = 1.50 \/ 1_000_000\nRATE_OUTPUT       = 7.50 \/ 1_000_000\n\num         = resp.usage_metadata\ncached     = getattr(um, \"cached_content_token_count\", 0) or 0\nprompt_tok = getattr(um, \"prompt_token_count\", 0) or 0\nout_tok    = getattr(um, \"candidates_token_count\", 0) or 0\nnon_cached = max(prompt_tok - cached, 0)\ncost       = (cached * RATE_INPUT_CACHED + non_cached * RATE_INPUT_STD + out_tok * RATE_OUTPUT)\n\nbudget_ref.update({\"CurrentSpendUSD\": firestore.Increment(cost)})\n<\/code><\/pre>\n\n\n\n
    Notice the distinction between cached and non-cached input tokens<\/strong>. When the context cache is active, site content tokens are billed at 1\/10th the standard rate. When the cache is missing or expired, those same tokens are billed at the full rate. The agent tracks both separately because they represent fundamentally different cost profiles.<\/p>\n\n\n\n
    The cost is accumulated in Firestore using firestore.Increment()<\/code> \u2014 an atomic operation that prevents race conditions even under concurrent requests.<\/p>\n\n\n\n
    Monthly Budget Lifecycle<\/h3>\n\n\n\n
    The budget isn’t just tracked, it’s governed through a four-stage lifecycle:<\/p>\n\n\n\n
    Track<\/strong> \u2192 Every request calculates and accumulates its cost.<\/p>\n\n\n\n
    Monitor<\/strong> \u2192 A scheduled job runs every four hours, checking spend against two thresholds:<\/p>\n\n\n\n