The "boring engineering" inside Avery NXR

Most product blog posts focus on user-visible features. Templates, connectors, capabilities.

This post is different. It's about the engineering that users never see directly but that determines whether the product actually works in production.

Software companies don't talk about boring engineering enough. We think they should. Here's the boring engineering inside Avery NXR.

Why "boring engineering" matters

Every software product has two layers:

→ The user-visible layer. What users see and interact with. Features. UI. Workflows.

→ The infrastructure layer. What makes the user-visible layer reliable. Underneath the surface.

Most companies talk about the user-visible layer because that's what sells. Templates are easier to demo than connection pooling.

But the infrastructure layer determines whether the product is durable. A product with great features and broken infrastructure becomes frustrating fast. A product with good features and excellent infrastructure quietly wins.

We've invested heavily in the infrastructure layer. Here's what's in it.

Engineering 1: Reliable connector framework

We have 63 connectors. Each one needs to handle:

→ Authentication (OAuth flows, API keys, token refresh) → Rate limiting (each service has different limits) → Pagination (large result sets need handling) → Error handling (transient vs. permanent errors) → Retries with exponential backoff → Timeout handling → Response parsing (each API returns different shapes) → Version handling (APIs change over time)

Doing this WELL for one connector takes 2-4 days of engineering. Doing it for 63 means a significant engineering investment.

The infrastructure is a framework that handles the common concerns (auth, rate limiting, retries) so each new connector is mostly about specifics (this API uses these endpoints, returns this shape).

Result: connectors work reliably. When something breaks, it's usually obvious and fixable.

Engineering 2: Local model runtime integration

Avery NXR works with Ollama. Connecting cleanly required:

→ Process management (Ollama service lifecycle) → Model discovery (which models are installed?) → Memory management (which models fit current RAM?) → Concurrent request handling (multiple agents using same model) → Error recovery (model crashes, OOM, etc.) → Performance monitoring (track tokens/second per model) → Hardware adaptation (Apple Silicon vs NVIDIA vs CPU)

The integration is thin in user-visible terms but deep in engineering. Users get a model dropdown. Underneath: substantial work to make the dropdown reliable.

Engineering 3: Audit ledger that scales

The audit ledger captures every agent execution with full traceability. To do this without slowing down agents:

→ Asynchronous write path (logging doesn't block agent execution) → Structured JSON Lines format (queryable with grep + jq) → Configurable retention (some users keep days, some keep years) → PII redaction (sensitive fields obscured by default) → Compaction (older logs compressed efficiently) → Query interface (search by agent, time, outcome, etc.) → Export capability (CSV, JSON, custom formats)

Audit ledger could be a logfile. We've made it a useful tool. The difference is engineering.

Engineering 4: Workflow execution engine

When an agent runs, the workflow engine:

→ Parses YAML configuration → Resolves dependencies between steps → Manages step state across execution → Handles errors at each step appropriately → Tracks resource usage → Supports cancellation → Emits events for observability

This is the kind of engineering that's hard to even appreciate as a user. The workflow just runs. You don't see the orchestration.

But when workflow engines are bad, weird things happen. Workflows get stuck. Steps execute in wrong order. State gets corrupted. We've built ours carefully.

Engineering 5: Local-first sync (for collaboration)

When multiple users work on the same agent (Pro tier), changes need to sync without conflicts.

We use CRDTs (Conflict-free Replicated Data Types) for collaborative editing. Two users editing the same agent concurrently → changes merge without manual conflict resolution.

This is unusual for agent platforms. Most expect single-user editing. Our customers have asked for multi-user from day 1. The CRDT investment makes it work cleanly.

Engineering 6: Permission model

Pro and Enterprise tiers have role-based access. Building this required:

→ Identity (who is this user?) → Authentication (prove you're who you claim) → Authorization (what can this user do?) → Resource ownership (who owns this agent?) → Sharing rules (when does access propagate?) → Audit (who accessed what when?)

Most users never think about the permission model. It quietly enforces the right rules. When it works, it's invisible. When it fails, it's disastrous.

We've put real effort here. Mistakes in permission engineering are existential bugs.

Engineering 7: Deployment automation

Pro tier deploys to Vercel, Railway, or SSH on-prem. Each needs:

→ Build configuration → Environment variable management → Database setup (Postgres for state) → Background worker configuration (for async jobs) → Health checks → Update path (how to ship new versions) → Rollback path (when something goes wrong)

Customers click "Deploy to Railway" and it works. Underneath: substantial automation.

Engineering 8: Connector versioning

External APIs change. Without versioning, every API change breaks something.

Our approach:

→ Connectors target specific API versions → When source service releases new version, we test against new version → Updates are explicit, not automatic → Customers can pin to specific connector versions if they need stability → Migration paths exist when versions need to change

This is unglamorous engineering. It's also what keeps connectors working over years instead of breaking every few months.

Engineering 9: Observability for ourselves

We need to understand how our own product is performing. We've built:

→ Metrics collection (response times, error rates, agent execution counts) → Distributed tracing (follow a request across services) → Logging aggregation (debug across customer deployments without seeing customer data) → Anomaly detection (alert when something's off) → Capacity planning (forecast when we need to scale)

This isn't customer-visible. It's how we know whether our product is healthy without having to ask every customer.

Engineering 10: Security infrastructure

For local-first deployment, security comes built in. For Pro and Enterprise deployments:

→ Encryption at rest (database, files) → Encryption in transit (TLS everywhere) → Secret management (API keys stored properly) → Access logging (who accessed what) → Vulnerability scanning (CI/CD pipeline) → Dependency monitoring (alerts on new CVEs) → Penetration testing (regular external testing)

Boring. Critical. Done well, invisible. Done poorly, catastrophic.

What this engineering enables

When we make claims like:

→ "Avery NXR is reliable" → "Connectors work cleanly" → "Audit ledger is comprehensive" → "Multi-user collaboration works"

These claims are backed by the engineering above. Without the engineering, the claims would be marketing fluff.

This is why building a platform takes longer than building features. The platform is the engineering. The features are the visible expression of the engineering.

Why we share this publicly

Most companies don't talk about boring engineering. The work isn't dramatic. It doesn't make great demos.

We're sharing because:

→ It builds trust. When buyers understand the engineering depth, they understand why we can make reliability claims.

→ It informs hiring. Engineers we want to work with care about boring engineering. Talking about it attracts the right people.

→ It's interesting. Once you appreciate boring engineering, it's actually interesting. Many of the hardest technical problems are boring from the outside.

→ It honors the work. Boring engineering takes real talent. Not talking about it is unfair to the engineers who do it.

What this means for buyers

When you evaluate Avery NXR (or any platform), the user-visible features are easy to compare. Templates, connectors, capabilities — most platforms have similar surface.

The boring engineering is harder to evaluate but matters more. How does the platform handle errors? What's the retention pattern over months? How do permissions actually work? What happens when external APIs change?

These questions are harder to ask. The answers tell you whether the platform is durable.

We'd rather buyers evaluate us on the boring engineering than on demos. The demos are easy. The boring engineering is what makes the platform actually work.

The principle

Boring engineering is where durable products are built. Companies that invest in it look slower than companies that ship flashy features. The companies that survive long-term are usually the boring engineering companies.

If you've been wondering why some agent platforms feel reliable and others don't, the difference is usually the boring engineering layer. It's invisible. It determines everything.

→ avery.software — Free Desktop tier. The platform with extensive boring engineering you'll never see directly but will benefit from constantly.