Abstract
Business AI needs a control layer, not only another interface.
Atarla is building an ownership and control layer that keeps authorized context, agent authority, model selection, tool access, and operating policy under explicit control. The same layer is designed to run in Atarla Cloud, on infrastructure the customer already owns, on an Atarla Node, or across those locations together.
The central problem is not access to another chat interface. It is the fragmentation of business context across calls, schedules, cameras, payments, inventory, staff knowledge, devices, and software tools, and the absence of a single place where authority over that context is decided. Adding automation without a shared control layer creates another copy of the data, another permission boundary, and another failure mode.
Local-first describes a placement and control preference, not a requirement that every task execute on one physical machine. Work should begin from the customer's policy and the capability available close to it, then use managed or external services deliberately where they earn their place. Restaurants are the first proposed proving ground, not the limit.
A practical control plane that treats ownership, context, agent authority, deployment placement, and routing to outside services as one system rather than separate product features.
Problem definition
Useful intelligence is scattered across the operation.
A business may already have the raw material needed for better decisions: customer conversations, transaction records, calendars, staff procedures, device events, images, and local knowledge. These sources rarely share enough context to support coordinated action.
Cloud AI can be valuable, but access alone does not resolve control. A business still needs to decide what leaves the premises, which model receives it, what an agent may do, how actions are reviewed, how state is retained, and how the system behaves when connectivity or a provider fails.
Research question
Can one control layer preserve enough operational context and execute sufficiently useful bounded workflows to reduce coordination burden, while remaining understandable, recoverable, portable across deployment locations, and economical to operate?
Design thesis
Local first is a control order, not an isolation rule.
- Ownership is architectural.
- The business's working context, policy, and core execution should sit where the business can inspect, move, and revoke them.
- One layer, several execution locations.
- The control layer stays the same whether it runs in Atarla Cloud, on customer infrastructure, on an Atarla Node, or across them. Location is a deployment decision, not a different product.
- Agents receive jobs, not blanket authority.
- Give each agent an identity, narrow role, explicit tools, limits, review points, and a revocation path.
- Proximity is not trust.
- A service, device, or model earns no implicit trust by being local or customer owned. This follows the zero-trust position that trust is not granted based on network location or asset ownership.1
- Evidence remains visible.
- Separate observed results, founder-reported facts, design hypotheses, and future plans so readers can evaluate the work honestly.
Product boundary
Name the parts, so location stops defining the product.
Atarla has been described in earlier material as a customer-owned computing node. That framing made hardware the definition of the company. The durable definition is narrower and more useful: Atarla is the layer, and the Node is one way to run it.
Where a person reviews what agents propose, approves consequential actions, and reads the audit trail.
Coordinates authorized memory, agent authority, model selection, tool access, approvals, routing, and audit. This is the product.
Atarla operates the layer so a business does not have to. An option, not Atarla's identity.
The layer runs on servers or cloud accounts the customer already controls.
A supported appliance for local compute, storage, and continuity. No specifications, photography, or availability are claimed in this paper.
Execution and data placement split across the above according to sensitivity, capability, latency, cost, availability, and policy.
Why this matters: under the previous framing, cloud appeared only as an external dependency and hardware sat close to the center of the commercial package. Under this framing, the layer is the product, and every deployment location is a way to run it.
Proposed architecture
The layer stays fixed. Where it runs can change.
The layer is not a local model server. It coordinates intake, memory, identity, policy, agent execution, approvals, audit, and routing, and it presents the same contract regardless of where it is deployed.
Scroll the diagram sideways to see all of it
Functional layers
Connectors translate events from software, devices, and human workflows into a common event model.
Working state and durable knowledge retain provenance, scope, retention rules, and access controls.
Human, service, device, and agent identities receive explicit permissions and decision boundaries.
Agents plan and act through approved tools, with human review where consequence or uncertainty requires it.
Tasks run in the selected location or externally according to sensitivity, capability, latency, cost, and availability.
Logs, health signals, signed updates, backups, rollback, isolation, and revocation support safe operation.
Trust, privacy, and governance
Powerful actions and private data must remain legible.
Atarla's security direction draws from zero-trust principles: no identity, device, agent, or service should receive implicit trust solely because it is local or owned. NIST states the position directly, that zero trust assumes no implicit trust is granted to assets or user accounts based solely on physical or network location, or on asset ownership.1
Keeping primary context close to the work can reduce unnecessary copying and external exposure. It does not eliminate risk: a self-operated system still needs careful identity, encryption, physical protection, updates, backups, and incident recovery. The intended privacy principle is data minimization and policy-controlled sharing, not an unsupported promise that data can never be compromised.
Scroll the diagram sideways to see all of it
Treating dependencies as dependencies
External models, software packages, agents, tools, connectors, protocol servers, retrieved documents, and other ingested content are dependencies, not trusted authorities. Their instructions and outputs should be authenticated where applicable, scoped by policy, validated for their destination, and contained according to consequence.
The Model Context Protocol specification takes the same position, stating that descriptions of tool behavior such as annotations should be considered untrusted unless obtained from a trusted server, and its authorization model requires access tokens bound to the intended audience while explicitly forbidding a server from passing through the token it received.7
Start with no tool access; grant the minimum action and data scope required.
Require approval for consequential, ambiguous, financial, safety-related, or irreversible actions.
Separate workloads and credentials so a compromised component has a limited blast radius.
Record who or what acted, which policy applied, what changed, and how to investigate it.
Support revocation, rollback, safe modes, backups, and tested restoration procedures.
Use signed artifacts, controlled rollout, verification, and a path back to a known-good state.
Threat surfaces this design has to answer
Published guidance for language-model and agentic applications treats prompt injection, sensitive information disclosure, supply chain, improper output handling, and excessive agency as distinct risk classes, and OWASP maintains separate current guidance for agentic applications.56 The surfaces below map those classes to locations in the architecture rather than restating them as a generic list.
Model serving, sandboxing, resource limits, and egress restriction for anything an agent can reach.
Provenance for model weights and packages, pinned versions, and a path to revoke a compromised dependency.
Poisoned or over-broad context is an injection surface. Provenance and scope are the mitigation, not prompt wording.
Excessive agency comes from excessive functionality, permission, or autonomy. Each is constrained separately.
Audience-bound tokens, no pass-through of received credentials, and short-lived scoped access.
Model output reaching a shell, query, browser, or device is validated for its destination, not trusted because it looks reasonable.
Risk management is intended to be continuous across the lifecycle, consistent with the NIST AI RMF functions of Govern, Map, Measure, and Manage.2 The framework is a reference, not a certification claim, and NIST has a revision of it underway.
Security boundary: customer ownership does not make a system invulnerable. Self-operated infrastructure introduces physical access, patching, credential, supply-chain, and operational risks that must be tested explicitly. Standards move; this section states a review date rather than claiming permanent alignment. Standards reviewed 28 August 2026.
Offline, hybrid, and failure behavior
Say what still works when something is down.
Local-first is often heard as a promise that everything keeps working offline. That promise is easy to make and hard to keep, so this paper states it as a behavior contract to be tested rather than a marketing property.
Intended behavior: locally deployed workloads continue, queued external work is held rather than dropped, and the operator can see what is deferred. Under test.
Intended behavior: routing falls back to a permitted alternative or declines the task explicitly. A silent downgrade in quality is a failure, not a fallback.
Intended behavior: emergency pause stops further proposals and actions, existing audit records are preserved, and the operator can reconstruct what happened.
Intended behavior: policy, memory scope, and audit history remain intelligible across locations. Portability is a research question in the plan below, not a settled property.
Each row is a claim the research plan has to try to falsify. None of them is currently presented as a measured result.
Research and validation plan
Turn the thesis into falsifiable work.
A credible R&D program should identify the high-risk technical questions, describe how each will be tested, and define what evidence would justify continued development. This mirrors NSF's emphasis on technical innovation, objectives and challenges, market opportunity, and team.8
Prototype a small set of real connectors and replay missing, duplicated, delayed, and conflicting events.
Trace completeness, deduplication, recovery, and operator understanding.
Compare policy-selected local and external execution on bounded tasks using the same acceptance rubric.
Quality, latency, cost, data exposure, fallback success, and routing rationale.
Test role templates, approval thresholds, revocation, and adversarial or ambiguous requests.
Unauthorized-action rate, approval burden, audit reconstruction, containment, and recovery time.
Run narrow before-and-after workflow studies with consent and a documented baseline.
Time, correction frequency, intervention rate, operator confidence, and failure analysis.
Run the same bounded workflow in a managed deployment, on customer infrastructure, and on prototype hardware.
Behavioral equivalence, policy portability, audit continuity, and the cost of moving between locations.
Induce connectivity loss, provider outage, credential expiry, and a misbehaving agent. Exercise emergency pause and rollback.
Deferred-work integrity, absence of silent downgrade, pause latency, and audit reconstruction after recovery.
Adversarial testing with injected instructions in retrieved documents, tool output, and third-party responses.
Unauthorized-action rate, whether policy held independently of model behavior, and containment of any successful attempt.
Measurement discipline
- Define each workflow, baseline, success condition, and exclusion before collecting results.
- Report sample size, hardware and software configuration, model versions, connectivity, and test date.
- Preserve failed runs and operator interventions rather than publishing only favorable examples.
- Separate laboratory measures from field observations and avoid generalizing beyond the tested setting.
- Publish benchmark or customer outcome claims only after the evidence and permission exist.
Initial market and commercialization logic
Restaurants are a proving ground, not the ceiling.
Restaurants compress time-sensitive communication, staffing, scheduling, payments, inventory, cameras, equipment, marketing, and coordination into one environment. That density makes the category useful for learning whether an owned control layer can reduce fragmented work.
The commercialization hypothesis is layer-led rather than hardware-dependent. A managed deployment can lower adoption friction. Customer infrastructure can give a business more direct control. An Atarla Node can package local execution and lifecycle support into a supported appliance. Hybrid deployments can combine them. Possible revenue surfaces include managed operation, usage-based compute, business and fleet features, supported hardware, support services, and ecosystem participation.
These are hypotheses, not a catalog. No offering listed above is presented as commercially available, and no pricing, unit economics, channel strategy, or market-size forecast is claimed. Each would have to be validated before it is offered.
Alternatives and differentiation hypothesis
Fast access to capable models, but context and control remain divided among providers.
Useful for a defined workflow, but may not provide shared memory, policy, or device coordination.
Provide local compute, but do not necessarily include a governed agent and business-context layer.
Unifies authorized context, bounded agents, deployment choice, operations, and selective outside routing behind one control layer. The advantage remains a hypothesis to validate.
Evidence, assumptions, and limitations
State what is known, and label everything else.
A Raspberry Pi 5 prototype with external cooling exists. A web application is in invite-only testing. Incorporation has been applied for and is pending.
The public website and its published documents can be inspected directly, including the architecture descriptions and security boundaries stated in them. Source repositories are currently private, so the code itself is not yet independently inspectable.
Production hardware, repeatable outcomes, broader integrations, and a selectively open-source path for safe software and interfaces - without exposing unencrypted hardware access or secrets.
Production readiness, certifications, patents, benchmark leadership, customer outcome figures, broad deployments, grants, accelerator acceptance, confirmed partnerships, or incorporation completion.
Capability status
Every capability below carries a status so that a design description is never read as a shipped feature.
Available is not used anywhere in this table. Nothing described in this paper is generally available.
Material limitations
- The present evidence base is too small for performance or market conclusions.
- A solo-founder team creates execution, domain-coverage, and continuity risk; specialist collaborators and advisors will be needed.
- Local hardware adds deployment, support, lifecycle, and physical-security responsibilities that pure software products may avoid.
- Third-party models and business systems can change behavior, pricing, availability, and API terms.
- Restaurant workflows can involve employees, customers, cameras, payments, and sensitive data; consent, privacy, labor, and sector requirements must be evaluated before deployment.
Development path
Milestones should retire risk, not decorate a timeline.
Use the Raspberry Pi 5 prototype to document workflows, establish baselines, and identify minimum connector, policy, privacy, and recovery requirements.
Demonstrate one bounded workflow end to end, including failure handling, audit reconstruction, and routing decisions.
Evaluate operator value, intervention burden, reliability, privacy, and support needs in a limited real environment.
Address lifecycle, secure updates, fleet operations, documentation, support, cost, repeatable installation, and an open-source release plan that does not expose secrets or unsafe device access.
No production date is implied. Advancement between gates should depend on evidence, not a predetermined calendar.
Collaboration and funding fit
Ask for the help that closes a named gap.
Accelerators, R&D programs, grant reviewers, sponsors, and technical partners evaluate different outcomes. Atarla should approach each with a specific work package and matching evidence request rather than one generic sponsorship pitch.
Fit: high-risk validation in orchestration, agent containment, routing, evaluation, and recovery. Useful support: research planning, test infrastructure, subject experts, and funding tied to measurable objectives.
Fit: founder development, customer discovery, team formation, market validation, and disciplined milestones. Strong evidence is clear communication, credible progress, learning velocity, and a reason this team can execute.
Fit: models, silicon, edge hardware, integrations, security tooling, observability, and deployment operations. A useful partnership starts with a bounded compatibility or evaluation project.
Fit: a specific operating problem, safe test boundary, access to domain feedback, and a mutually useful learning agenda. Public claims require permission and defensible results.
Current conversation: Atarla is seeking technically rigorous feedback, domain collaborators, pilot design partners, and programs suited to early R&D. The immediate goal is to turn the architecture into measurable evidence.
Conclusion
Own the layer, not just the box.
If AI is going to participate in the operational life of a business, the business needs more than an interface. It needs an accountable place where context, authority, execution, and recovery are decided.
Atarla's proposed answer is a control layer the customer can own and move, running in Atarla Cloud, on their own infrastructure, on an Atarla Node, or across them. Hardware is one way to run that layer, not the definition of the company. The direction is early. Its value has to be shown through narrow workflows, transparent methods, measured failures, and honest evidence. That is the work ahead.
References
Standards and program criteria informing this direction.
- 01Rose et al. (2020). NIST SP 800-207: Zero Trust Architecture.
- 02NIST (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1.
- 03NIST (2024). AI RMF: Generative Artificial Intelligence Profile, NIST AI 600-1.
- 04Iorga et al. (2018). NIST SP 500-325: Fog Computing Conceptual Model.
- 05OWASP GenAI Security Project (2026). OWASP GenAI LLM Top 10 2026.
- 06OWASP GenAI Security Project (2026). OWASP Top 10 for Agentic Applications.
- 07Model Context Protocol specification, version 2025-11-25.
- 08America's Seed Fund powered by NSF. Project Pitch: key elements and instructions.
- 09U.S. Small Business Administration. SBIR/STTR program policies and evaluation considerations.
References provide conceptual and evaluation guidance. Their inclusion does not imply NIST, NSF, SBA, or any other organization endorses Atarla.