Abstract
Business AI should begin on infrastructure the business controls.
Atarla is building toward a customer-owned computing node that keeps operational context, policy, and agent execution close to the work, while retaining the option to use external models and cloud compute when they provide a clear advantage.
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. Adding automation without a shared control layer can create another copy of data, another permission boundary, and another failure mode.
The proposed architecture combines local compute, persistent memory, identity-aware permissions, bounded agent execution, observability, and policy-controlled routing to outside services. Restaurants are the first proposed proving ground, not the limit: the same pattern is intended to serve a one-person operation, small and mid-sized businesses, and, over time, larger organizations that need more control over operational AI.
A practical control plane that treats ownership, privacy, context, agent authority, and local-to-cloud routing 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 a small-business-owned node preserve enough operational context and execute sufficiently useful bounded workflows to reduce coordination burden, while remaining understandable, recoverable, and economical to operate?
Design thesis
Local first is a control order, not an isolation rule.
- Ownership is architectural.
- Keep the business's working context, policy, and core execution on customer-controlled infrastructure where practical.
- Agents receive jobs, not blanket authority.
- Give each agent an identity, narrow role, explicit tools, limits, review points, and a revocation path.
- Outside compute remains available.
- Route selected work to external models by policy when quality, specialization, latency, cost, or capacity justifies it.
- Evidence remains visible.
- Separate observed results, founder-reported facts, design hypotheses, and future plans so readers can evaluate the work honestly.
Proposed architecture
One owned operational layer between signals and action.
The proposed node is not merely a local model server. It is intended to coordinate data intake, memory, policy, agent execution, approvals, and selective external routing.
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 locally 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. Authentication and authorization should precede access, and policy should protect resources and actions rather than rely only on a network perimeter.1
Keeping the primary context at the edge can reduce unnecessary copying and external exposure. It does not eliminate risk: a local 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.
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.
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.
Security boundary: customer ownership does not make a system invulnerable. Local infrastructure introduces physical access, patching, credential, supply-chain, and operational risks that must be tested explicitly.
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.5
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.
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 intelligence layer can reduce fragmented work.
The initial commercial hypothesis is a combined hardware, software, and support relationship for businesses that value control, continuity, and coordinated automation. Pricing, unit economics, channel strategy, and service requirements remain to be validated; this paper does not present invented market-size or revenue forecasts.
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 owned compute, persistent context, bounded agents, operations, and selective outside routing. 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, its source history, architecture descriptions, security boundaries, and published documents can be inspected.
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.
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
Put the computer before the chatbot.
If AI is going to participate in the physical and operational life of a business, the business needs more than an interface. It needs an accountable place for context, policy, execution, and recovery.
Atarla's proposed answer is a customer-owned, local-first node that coordinates bounded agents and uses outside intelligence intentionally. The direction is early. Its value must be demonstrated 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).
- 03Autio et al. (2024). NIST AI 600-1: Generative Artificial Intelligence Profile.
- 04Iorga et al. (2018). NIST SP 500-325: Fog Computing Conceptual Model.
- 05America's Seed Fund powered by NSF. Project Pitch: key elements and instructions.
- 06U.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.