AUTOIA by Digiterráneo

A practical AI agent that turns business requests into safe, auditable actions across leads, CRM, email, documents and workflows—with human approval for sensitive steps.

Comment

Short description

AUTOIA helps a small business describe an operational problem in everyday language and receive a structured first automation diagnosis. The Build Week prototype uses GPT-5.6 through a secure local Node.js boundary, validates the result against a JSON schema, and clearly labels whether the response came from the model or from a deterministic fallback.

This is a working local prototype, not a production automation platform. It does not persist conversations, capture real leads, or connect to CRM, WhatsApp, email, calendars, or databases.

Inspiration

Small businesses rarely begin with an architecture diagram. They begin with a practical problem: enquiries arrive through different channels, repetitive tasks consume attention, follow-ups get lost, and teams are unsure what should be automated first.

Most automation conversations start with tools. AUTOIA starts with the business process. We wanted to build an approachable first step that listens to a problem, identifies the underlying need, recommends a realistic automation, asks the questions that still matter, and proposes a controlled next action. The goal is not to pretend that one prompt can redesign a company. It is to make the first automation decision clearer and more useful for people who are not AI specialists.

What it does

A visitor describes a business process in free text. AUTOIA sends that description to its local backend, where the input is validated before a request is made to GPT-5.6. The interface then presents five structured areas:

  1. the operational need detected;
  2. the recommended automation;
  3. the expected operational benefit;
  4. three follow-up questions needed to refine the diagnosis;
  5. the proposed next action.

The user can see whether the diagnosis came from GPT-5.6 or from the deterministic fallback. If the model is unavailable, times out, returns an HTTP error, produces invalid output, or identifies as a different model, AUTOIA preserves the flow without presenting the fallback as AI-generated.

The broader landing experience explains AUTOIA's services and includes guided answers and a contact form. In this prototype, the form validates the interaction and shows the intended next step, but it deliberately does not transmit or store any data.

Why it belongs in Work & Productivity

AUTOIA is designed around a recurring workplace problem: deciding where automation can create practical value before investing in a complex implementation. It helps companies, independent professionals, and local businesses turn an unstructured operational concern into a consistent brief that can support a human discovery conversation.

The prototype does not claim measured productivity gains or commercial results. Its contribution is a focused workflow that reduces ambiguity at the beginning of an automation project and makes the model's recommendation easier to inspect, discuss, and refine.

How we built it

We kept the architecture intentionally small and observable:

  • semantic HTML, CSS, and browser JavaScript provide the responsive experience;
  • a local Node.js 24 server delivers the page and exposes POST /api/diagnostico;
  • the server calls the OpenAI Responses API with gpt-5.6-sol;
  • reasoning: low, store: false, and Structured Outputs with JSON Schema constrain the model request;
  • server-side validation checks input length, request size, model identity, and output shape;
  • a time limit and deterministic fallback cover service and validation failures;
  • the API key is read only on the server from a Git-ignored local environment file;
  • the browser receives the structured result, never the API credential;
  • Git, a frozen base commit, and the build-week-2026 branch preserve the boundary between the earlier product and the Build Week work.

AUTOIA does not write prompts or diagnoses to application storage. The model request uses store: false, and no database, CRM, messaging service, or production system is connected.

How we used GPT-5.6

GPT-5.6 performs one narrow, high-value task: translating a free-form description of a business process into a schema-constrained automation diagnosis. The requested and verified model is gpt-5.6-sol through the Responses API.

The model does not control the interface, send messages, modify records, or execute an automation. The server requests a structured object containing the detected need, recommendation, expected benefit, three refinement questions, and next action. It then validates the response before returning it to the browser.

We chose this constrained design so that GPT-5.6 adds interpretation where rules alone would be brittle, while the application retains control of validation, presentation, failure handling, and user-facing disclosure. A real smoke test with fictitious business data returned gpt-5.6-sol and a valid structured diagnosis.

How we used Codex

Codex acted as an engineering collaborator throughout Build Week. We used it to:

  • audit the existing project and distinguish working, simulated, and future capabilities;
  • freeze the pre-Build Week state and establish a traceable Build Week branch;
  • define a defensible MVP rather than expanding the product vision;
  • implement the local server boundary and connect the diagnosis interface;
  • design the Structured Outputs schema, validation, timeout, and fallback behavior;
  • create and run automated tests for success and failure paths;
  • perform desktop and mobile browser checks;
  • identify and correct a transparent submit-button defect;
  • audit technical claims against code, tests, captures, and commits;
  • prepare the demo flow, evidence, and submission materials.

The Codex Session ID associated with the submission is recorded in the submission details above.

What existed before Build Week

AUTOIA was an existing Digiterráneo product concept before Build Week. The following foundations already existed:

  • the AUTOIA by Digiterráneo identity and commercial positioning;
  • the landing-page concept and service descriptions;
  • a browser-based guided assistant and local contact-form experience;
  • product documentation covering the commercial agent, conversation flow, lead model, master prompt, and roadmap;
  • the broader vision for agents, lead generation, CRM, document automation, and digital integrations.

Those foundations are disclosed as pre-existing work. They are not presented as features created during Build Week, and the broader roadmap is not presented as operational.

What we built during Build Week

The Build Week contribution transformed the existing browser experience into a verifiable GPT-5.6 diagnostic prototype. New work includes:

  • a local Node.js backend and POST /api/diagnostico endpoint;
  • a real Responses API integration using gpt-5.6-sol;
  • a JSON Schema for the five-part diagnosis;
  • secure server-side environment handling;
  • input validation, a 16 KiB body limit, timeout handling, and restricted local file delivery;
  • model-identity and output validation;
  • a deterministic, visibly labelled fallback;
  • integration of the diagnosis flow into the existing interface;
  • an automated test suite and a real smoke test with fictitious data;
  • desktop and mobile end-to-end verification and visual evidence;
  • a user-interface correction discovered during testing;
  • Git traceability, scope documentation, demo planning, and submission evidence.

This separation is backed by the frozen base commit and subsequent commits on the Build Week branch.

Challenges we ran into

Choosing a narrow, honest build

AUTOIA has a broad commercial roadmap. The hardest product decision was to avoid simulating a full automation platform. We reduced the submission to one complete loop: describe a process, receive a structured diagnosis, understand its source, and see the next step.

Protecting the API credential

The original experience was browser-only. A direct model call from the page would have exposed the credential, so we introduced the smallest useful server boundary and kept the key outside the client and Git.

Treating failure as part of the interface

A demo that silently replaces a model response can mislead users. We made the fallback deterministic and explicitly labelled, and we test timeout, remote failure, invalid output, and unexpected model identity.

Keeping model output predictable without removing its value

The input is intentionally open-ended, but the result must be understandable and consistently rendered. Structured Outputs let GPT-5.6 interpret the business context while a strict schema keeps the application contract stable.

Accomplishments that we're proud of

  • We completed a real end-to-end GPT-5.6 diagnosis path while keeping the API key out of the browser.
  • We created a structured response contract that the interface can validate and render consistently.
  • We built an honest fallback that remains useful without impersonating the model.
  • All 12 automated tests passed on the verified Build Week build.
  • A live smoke test passed with fictitious data and confirmed that the requested and returned model was gpt-5.6-sol.
  • Desktop testing at 1280 × 720 and mobile testing at 390 × 844 completed without console errors or horizontal overflow.
  • We found a visual defect during testing, fixed it, and repeated the checks instead of treating the first run as final.
  • We maintained a clear boundary between operational functionality, simulation, and roadmap.

What we learned

  • A narrow, observable AI workflow is more credible than a wide collection of simulated integrations.
  • Structured Outputs improve both reliability and interface design because the application can reason about a stable contract.
  • Fallback behavior is part of the product experience and should be disclosed, tested, and visually distinguishable.
  • Model identity should be verified before the interface labels a result as coming from the intended model.
  • Privacy and human review need to be designed before real lead capture, not added after deployment.
  • Codex is especially valuable when it combines implementation with testing, scope control, and claim auditing.

Testing

The verified local build was tested on July 18, 2026 with Node.js 24.

Automated suite: 12 of 12 passed

The suite covers:

  • health information without exposing credentials;
  • labelled fallback when no API key is available;
  • input-length validation;
  • rejection of request bodies larger than 16 KiB;
  • the Responses API request shape, including reasoning: low, store: false, and JSON Schema;
  • fallback after a remote HTTP failure;
  • fallback after invalid structured output;
  • rejection of disproportionate structured text before rendering;
  • refusal to label a response as GPT-5.6 when another model is returned;
  • cancellation after the request time limit;
  • delivery of the landing with a restrictive content policy;
  • prevention of public access to backend, environment, and backup files.

Live smoke test

A controlled request using fictitious business data returned a valid structured diagnosis with three questions. The requested and returned model was gpt-5.6-sol. No API key or complete interaction text is included in the evidence.

Browser verification

  • Desktop: 1280 × 720, passed.
  • Mobile: 390 × 844, passed without horizontal overflow.
  • Console errors during the verified journeys: zero.
  • Visual regression found a transparent submit button; it was corrected and retested.

These results describe the recorded local build at the time of testing. They do not demonstrate continuous availability, production readiness, load capacity, or measured business impact. Tablet, comprehensive keyboard accessibility, security penetration, and load testing are outside the current verified scope.

Current limitations

  • The prototype runs locally and is not presented as a production deployment.
  • The contact form is simulated and does not send or store information.
  • Prompts and diagnoses are not persisted by the application.
  • There is no connected CRM, database, WhatsApp, email, calendar, analytics, authentication, or multi-company panel.
  • AUTOIA recommends an automation but does not execute that automation in this build.
  • The fallback is rules-based and intentionally identified as such.
  • The prototype has not been validated with real customers, and we make no claims about users, conversion, revenue, time saved, or accuracy rates.
  • The tested browser scope is desktop and mobile; it is not a claim of exhaustive compatibility or accessibility certification.
  • Human review, consent, retention rules, monitoring, and production cost controls are required before real business use.

What's next

Our next milestone is not to add every possible integration. It is to take one diagnosis through a safe, consented operational handoff. The planned sequence is:

  1. add an approved, source-aware knowledge base;
  2. introduce human review and explicit consent before any data is retained;
  3. persist only the minimum approved lead information;
  4. connect one CRM or notification destination end to end;
  5. add authentication, observability, cost controls, and production hardening;
  6. test the workflow with consenting businesses and measure outcomes before making impact claims;
  7. expand to document automation and additional channels only after the core handoff is reliable.

Accuracy statement

This submission describes a controlled local Build Week prototype. It does not claim that CRM, persistence, messaging, production deployment, or guaranteed business outcomes are active. Every technical claim above is limited to the tested build and is supported by code, automated tests, browser verification, captures, or Git history.

Built With

Share this project:

Updates