Autessa Blog

Notes on building AI systems that work in production.

Long-form writing on AI infrastructure, agent evaluation, vision-based automation, capability-based agent architecture, internal tooling, drift detection, data security, and unified agent memory.

View all posts as markdown

Autessa Philosophy

3 posts
Dogfooding versus customer zero Left: a product used internally as a test, with the real business running on a separate fallback stack. Right: the product as the sole system of record, with no fallback. If it fails, the business stops. Dogfooding The business Real work, real stakes Your product Internal pilot, subset of use uses Fallback stack Spreadsheets, SaaS, email if it fails → The product is used when convenient. If it breaks, the team switches tools and files a bug report. Bugs are tickets, not obstacles in someone's workday. Customer zero Your product System of record for the business Recruiting Every candidate Sales Every deal Operations Every decision Internal tools Every workflow No fallback. No safety net. No alternative. If the product fails, the business stops. Bugs are obstacles in someone's workday that demand immediate resolution. That is what makes the feedback loop honest.
Philosophy

What Is Customer Zero, and Why Do the Best Platform Companies Practice It?

Customer zero means running your business on the product you sell — not as a test, but as the system of record. A look at where the idea came from and why it shapes the best platform companies.

9 min read·.md
Fragmented business stack versus Autessa running everything Left: business functions scattered across Gmail, Notion, Google Drive, and an external CRM, connected by fragile glue. Right: the same functions all flowing into AutessaDB with Prism, Lens, and Forge as internal layers. A typical business stack Recruiting Sales Operations Internal tools Gmail Threads CRM Pipeline Notion Docs Sheets The glue Context is lost in the handoff between where work happens and where data lives. No question has the full picture behind it — only the sales picture, or the recruiting one. Autessa, every function Recruiting Sales Operations Internal Autessa One platform, one system of record AutessaDB Every record, every context Prism Evaluates agent output Lens Reaches the rest Forge Builds the tools we need Every question has the full picture behind it. We find the problems first — before customers do.
Philosophy

How Autessa Runs Its Entire Business on Autessa

We are our own first customer. Every conversation, every candidate, every deal, and every decision runs on the same platform we sell — including the moments that commitment gets tested.

10 min read·.md

Building

11 posts
Four fragmented systems versus one converged platform Left: Postgres, Pinecone, Kafka, and S3 connected by tangled integration arrows. Right: a single AutessaDB box containing the same primitives as internal layers. Four systems, four boundaries PostgreSQL Relational records Pinecone Vector embeddings Kafka Event streams S3 Object storage Integration layer: four auth models, four encryption configs, four audit trails One system, one boundary AutessaDB PostgreSQL-based converged data layer Relational Rows and joins Vector Similarity search Events Streams and triggers Objects Files and blobs One access model. One encryption layer. One audit trail.
Infrastructure

Why Do AI Projects End Up With So Many Infrastructure Systems?

How AI infrastructure sprawl happens, what it actually costs, and why convergence beats consolidation.

9 min read·.md
Four-dimension agent evaluation with v1 and v2 overlay A radar chart plotting groundedness, task completeness, argument faithfulness, and efficiency for agent v1 and agent v2. v2 is stronger on completeness but weaker on groundedness. Groundedness Task completeness Argument faithfulness Efficiency 75 50 25 Agent v1 Baseline Agent v2 New retrieval strategy v2 completeness: +12% v2 groundedness: −8% Ship decision requires weighing both axes.
Evaluation

How Should You Evaluate AI Agents in Production?

Why spot-checking fails, which four dimensions actually matter, and how continuous evaluation catches regressions before your users do.

10 min read·.md
CSS selectors versus visual understanding of a form Two copies of the same login form. The left highlights the CSS selectors an RPA script memorizes. The right highlights the visual labels and spatial cues a vision-based agent reads. Traditional RPA sees the DOM Sign in Email input#user_email Password input[name="pw"] Sign in .form-actions > button.primary Vendor ships a CSS refactor → selectors change → script breaks. Vision-based agent sees the screen Sign in Email label: "Email" Password label: "Password" Sign in visible text: "Sign in" Vendor ships a CSS refactor → labels unchanged → automation still works.
Automation

Why Do Automated UI Workflows Break When an Application Updates?

Traditional RPA sees the DOM. Humans see the screen. That gap is why your automations break every time a vendor ships a redesign.

8 min read·.md
Hardcoded decision tree versus capability-based agent Left: a deeply nested if-else decision tree with many branches. Right: a flat set of declarative capabilities that the agent dynamically selects from at runtime. Hardcoded decision tree customer query order question? refund request? other window open? loyalty tier? exists? call A call B call C call D call E call F Every new business rule → new branch → sprint ticket. 243 paths at 5 decision points, 729 at 6. Emergent behavior nobody designed. Capability-based agent Runtime reasoning check_order_status input: order_id refund.standard max: $500 refund.loyalty_exception requires: loyalty_tier escalate_human no constraints Each capability: description, inputs, constraints. Agent selects at runtime. New rule → add a capability, not a branch.
Agent Architecture

Why Do AI Agents Become Brittle Workflow Engines Instead of Intelligent Systems?

Most agent architectures devolve into decision trees with an LLM in the middle. Here's why, and what a capability-based alternative looks like.

8 min read·.md
Internal tools backlog: arrivals outpace delivery, shadow IT fills the gap A line chart showing request arrivals climbing faster than delivery throughput over four quarters, with the widening gap labeled as the growing backlog and a dotted line branching off labeled shadow IT. Demand outpaces supply Q1 Q2 Q3 Q4 tools 0 10 20 30 40 Requested Delivered Shadow IT unofficial tools backlog widens Arrivals new tool requests / quarter Delivery engineering throughput Shadow IT spreadsheets, Airtable, unofficial
Internal Tools

Why Is the Internal Tools Backlog Always Six Months Long?

Engineering cannot keep up with internal tool demand. People build shadow IT to cope. AI-generated tooling changes the math.

8 min read·.md
Groundedness score slowly declining over six months A line chart of an AI application's groundedness score declining gradually from near-perfect to the abandonment threshold over six months, with three horizontal bands: still useful, trust eroding, quietly abandoned. Drift, not failure Still trusted Trust eroding Quietly abandoned 100% 85% 70% 60% Groundedness launch month 1 month 2 month 3 month 4 month 5 month 6 No alert fires. No ticket filed. Users start double-checking. The tool feels "off." People stop using it. Still running. Still costing money. Continuous scoring catches the 3 percent monthly slope weeks before users complain.
Operations

Why Do Internal AI Applications Stop Working After Six Months?

AI applications do not crash. They drift. Here's how gradual degradation erodes trust, and what it takes to keep AI tools aligned with a changing business.

8 min read·.md
Four perimeters versus one perimeter Left: the same customer record replicated into four systems, each with its own padlock and its own access control. Right: one perimeter around a single data layer where field-level policies travel with the data. Four perimeters, inconsistent PostgreSQL customer.ssn masked ✓ ✓ Vector store embedding of ssn... masked ✗ ✗ Event stream conv.ssn (plaintext) retention: none ✗ Object store contract.pdf AES-256 ✓ ✓ Four access models. Four encryption configs. Gaps live in the seams. One perimeter, consistent AutessaDB Field-level policy travels with the data customer.ssn → masked everywhere customer.embedding → respects masking conversation stream → same retention ✓ One access model. One encryption layer. The security boundary is the data itself.
Security

How Do You Secure AI Application Data When It Is Spread Across Multiple Systems?

The real security risk in AI applications is not in any single system. It lives in the seams between four.

9 min read·.md
Dynamic memory and static memory unified under one query An agent in the center reaches into a unified memory layer that contains both dynamic memory (conversation history, observed events, accumulated state) and static memory (policies, contracts, manuals). One query, two kinds of memory unified memory layer · one search path · one access model Dynamic memory what the agent has learned, observed, accumulated • Recent conversation history • Customer account state • Processed events (team updates, invoices) • Patterns recognized over time changes minute-to-minute Static memory curated knowledge humans maintain • Policy documents, contracts • Product manuals and specs • Compliance guidelines • Folder hierarchy and cross-references changes rarely, versioned Agent The agent reasons across both in one pass, not four separate lookups.
Agent Memory

Why Do AI Agents Forget Everything Between Conversations, and Why Can They Not Search Your Files Properly?

Most agent limitations are not model limitations. They are memory limitations. Here's what unified dynamic and static memory unlocks.

11 min read·.md
Single point of failure versus dual point of failure architecture Left: agent connects directly through an MCP token to the system — one gate. Right: agent connects through a capability policy block, which then uses the MCP token to reach the system — two independent gates. MCP alone: single point of failure Agent authenticated MCP token System all actions one gate Credential compromised → any action proceeds. Prompt injection → any action proceeds. Misinterpretation → any action proceeds. With capability layer: dual point of failure Agent authenticated Capability policy block business rules MCP token System scoped action gate 1: policy block gate 2: token Two independent failures required: agent selects wrong action AND policy permits it. Policy block enforces: dollar limits, approval thresholds, customer eligibility, time-of-day rules. Agent cannot see or bypass the policy block.
Agent Architecture

Why MCP Is Not Enough: The Capability Layer Every Enterprise AI Agent Needs

MCP solves the integration problem. It does not solve the authorization problem. Here is the three-layer architecture that makes AI agents safe to deploy at scale.

6 min read·.md
The five ways a graphical interface gets built Five approaches laid left to right from predictable and human-owned to dynamic and machine-owned: static UI, per-company, per-user, per-page-load, and per-interaction. An accountability boundary sits between the user-owned and machine-owned approaches. Predictable Human owned Dynamic Machine owned accountability 01 / STATIC UI Built once, shipped to all Legacy web and classic SaaS frozen nobody adapts it Who bends The people adapt to the tool Fit + upkeep 02 / PER COMPANY Tailored for the team Hire a consultant to build it a hired human Who bends Software is fitted once Fit + upkeep 03 / PER USER Shaped by you, for you User-directed, then locked in "keep totals on top" locked in one shared backend you, in words Who bends User directs, then it is fixed Fit + upkeep 04 / PER PAGE LOAD Generated on sign-in Machine reads context, no human no human in loop the machine, live Who bends Machine chooses, no human Fit + upkeep 05 / PER INTERACTION The reply is the interface You type; it renders an answer show my spend the conversation Who bends Machine, fresh every question Fit + upkeep
AI Interfaces

Generative UI Isn't Always the Answer: The Five Ways an Interface Gets Built

Generated, conversational UI is treated as the future of every interface. Four decades of HCI research say it is one of five options, each right for different jobs. Here is the map and the evidence.

10 min read·.md
Build vs. buy vs. Autessa comparison Comparison of building AI in-house, buying an out-of-the-box solution, and the Autessa model across seven dimensions an agency cares about. Build in-house Buy off the shelf Build on Autessa Control over roadmap full Agency ownsevery decision low Vendor setsthe direction full Agency buildswhat it needs Security and governance self-built Every safeguardfrom scratch vendor's Opaque, hardto inspect platform-enforced Consistentacross all apps Speed to deploy slow Long, costlyto stand up fast Ready to run fast Build on aready foundation Customization to mission full Tailored, butexpensive fixed Another org'splaybook full Trained on agencydata and rules Data ownership retained Stays withthe agency leaves Flows to externalsystems retained Kept in governedenvironment Recoverability depends Only ifbuilt in limited No cleanrollback versioned Revert toknown-good state Proven ROI manual Tracked only ifinstrumented opaque Hard tomeasure value built-in Outcome metricsfrom day one
Government

Build vs. Buy for Government AI: Why the Smartest Agencies Are Choosing Both

The old build-versus-buy debate assumed agencies had to trade control for safety. A platform model lets government build the applications its mission requires on top of inherited governance, observability, and recoverability.

12 min read·.md