Read the operating details before sending a brief.

A commercial role can be configured to work continuously on incoming tasks, use a controlled browser, research public sources, complete approved templates and documents, draft content, coordinate calendars or appointments, and operate approved tools and workflows. Capabilities are enabled only when needed; sensitive or external actions stay permission-bound and human-approved. Public demos are intentionally narrower and do not imply that every capability is enabled.

It is a role-based software system configured around up to three agreed initial workflows. It triages work, follows up, updates approved records, prepares documents and reports, coordinates across tools, requests approval for sensitive actions, and hands exceptions to people with context.

No. A conversational interface can be part of the system, but the deliverable is a managed operational role: a defined queue, approved knowledge, selected tools, action limits, human handoff, and monitoring.

Six fictional workspaces cover dental, agriculture, accounting, legal, real-estate, and field-service operations. Each one includes role-specific navigation, synthetic records, and multi-step work for investigation, drafts, exception routing, approvals, and evidence review.

No. Public demos use synthetic records and simulated writes. Sensitive actions stop at an approval step, and no real patient, client, court, grower, property lead, supplier, or field-service customer is contacted.

Potentially. CodeAustral first validates supported access, permissions, data quality, rate limits, and recovery paths. An unsupported or unstable integration is narrowed, redesigned, or excluded before launch.

No. The employee uses the business channel you choose—your existing WhatsApp or Telegram. CodeAustral does not provide or require a second number. Channel access and policy fit are validated during onboarding.

Yes. CodeAustral configures up to three agreed initial workflows and teaches the operating method with reusable templates so your team can create, duplicate, test, and adjust its own. Additional professional design, implementation, or integrations are quoted separately according to complexity.

Only inside the permissions approved for that role. Financial, contractual, publishing, account, and other sensitive actions can require confirmation. Unknown or conflicting situations are escalated to a named owner.

Plans are USD 49, USD 99, and USD 199 per month, with annual billing available and no setup fee. Every plan includes the complete AI employee and the same capabilities. USD 49 runs on managed shared cloud; USD 99 and USD 199 run on a private managed VPS with progressively higher AI usage capacity.

The launch plan is set after CodeAustral validates the workflow, real examples, access, approval owners, and integrations. A role using reliable existing access is faster to validate than one that needs a custom connector or data cleanup.

The deployment pattern is selected during scope around the company’s data, security, network, and infrastructure requirements. Private infrastructure can be quoted when the role requires it.

Before launch, CodeAustral and the workflow owner define acceptance measures for the chosen queue, such as completion quality, processing time, handoff rate, error rate, or backlog reduction. The role is reviewed against those measures rather than judged as a generic AI demo.

CodeAustral designs and engineers custom web platforms, SaaS products, native iOS apps, applied AI systems, restaurant technology, integrations, and the operational infrastructure around them.

Send the current context, desired outcome, users, systems, constraints, and any existing product or code. The first response focuses on fit, unknowns, and the smallest credible next step before a delivery plan is proposed.

Timing depends on the product surface, existing code, integrations, review cycle, and launch requirements. CodeAustral provides a schedule only after the relevant scope and dependencies have been inspected.

Custom product work is estimated from the agreed scope, delivery mode, technical risk, dependencies, and support requirement. The written proposal separates assumptions, deliverables, exclusions, payment stages, and change handling.

Existing customer systems and assets remain theirs. Ownership, licences, repositories, third-party components, handoff, and any continuing hosting or support are defined explicitly in the written agreement for the engagement.

Yes. The engagement can begin with a product audit, a defined feature, an integration, a recovery effort, or a focused delivery track alongside an internal team. Access and decision ownership need to be clear before implementation starts.

The handoff or managed-support path is agreed before launch. It can include a defined correction period, monitoring, maintenance, release support, operational documentation, or an ongoing product roadmap.

Security requirements are mapped to the actual system, users, data, providers, access model, and deployment environment. Controls and responsibilities are documented for the specific engagement rather than assumed from a generic package.

CodeAustral validates critical providers and access paths before relying on them. A fragile dependency is isolated, given a recovery path, moved behind approval, replaced, or removed from scope instead of being hidden inside the implementation.

Yes through the change process agreed for the project. The impact on delivery, cost, acceptance, and dependencies is made explicit before the changed work becomes part of the commitment.