Artux is not a user interface placed over an open-source agent project. Its digital employee runtime, cloud control plane, and training and evaluation system were built in-house over 12 months beginning in August 2025. We should be equally precise about what was not built in-house: Artux does not train a foundation model and does not claim to. We own the engineering above the model—multi-agent orchestration, instance isolation, credentials, Feishu/Lark integration, memory governance, audit, safety gates, provisioning, and job training—because that layer determines where data goes, how failures recover, and whether product progress depends on another platform's roadmap.
What we built and what we did not
Artux uses Claude-family models through platform-managed Bedrock access, a customer-provided API key, or a supported subscription credential. Foundation-model research is a different business and pretending otherwise would make the rest of the architecture less credible. Artux is an independent product and is not endorsed by or affiliated with a model provider.
The in-house work consists of three systems:
| System | Responsibility |
|---|---|
| Digital employee runtime | Supervisor and specialist orchestration, Feishu/Lark, browser work, long-term memory |
| Cloud control plane | Tenants, subscriptions, provisioning, upgrades, key distribution, gateway, relay, seats, and quotas |
| Training and evaluation | Role manuals, skill packages, knowledge, behavioral evaluation, and reports |
The training system matters because a capable agent is not automatically competent in a company's operating procedures. In production, role knowledge became 59 skill packages, 81 knowledge documents, and 22,000 lines of role manuals.
A repository-backed timeline
| Date | Milestone |
|---|---|
| Aug 1, 2025 | First in-house operations-platform commit |
| Dec 10, 2025 | AI image platform and first in-house Shopify app |
| Jan 22, 2026 | Organization, login, messaging, and Feishu integration |
| Feb 27, 2026 | Operations and security system managing seven servers |
| Apr 20, 2026 | Digital employee system begins—the shift from tool to colleague |
| Jun 2, 2026 | GEO workstation begins with connectors and an audit engine |
| Jul 9, 2026 | User-scoped digital employee gateway goes live |
| Jul 14, 2026 | Multi-user, multi-site GEO production deployment |
| Jul 26, 2026 | GEO automation scheduler completed its release checks |
April 20 is the important boundary. Before it, software helped people calculate. After it, software had to execute safely when nobody watched it.
The digital employee system itself is about 90,000 lines, with 224 test files, 318 database migrations, and 503 commits. The 1,227,041-line figure describes all five in-house production systems, including the operations platform, Shopify ecosystem, and GEO workstation. Those numbers should never be presented as if Artux alone contained 1.23 million lines. The full account is in Nouhaus's 12-Month AI Journey.
Ownership makes data-boundary promises possible
“Data does not leave the environment” only means something when it can be decomposed:
- Every company receives a dedicated service and database rather than relying only on correct tenant filters in a shared database.
- Semantic retrieval uses an in-process embedding model rather than sending each conversation to an external embedding endpoint.
- AI and application secrets remain in the cloud gateway and can be revoked per instance instead of being written into tenant instances.
- Business-system authorization remains at the source. The gateway mints a restricted credential for the initiating user, and the target application decides what that user can access.
Each promise depends on control of the relevant code path. Engineering ownership is not a slogan here; it is the condition that lets the product make and verify those claims.
Ownership makes failures repairable
The expensive part of a stack assembled from opaque services is not necessarily licensing. It is an incident that stops at somebody else's backlog.
One production example involved public theme-preview links dropping parameters for unauthenticated browsers and redirecting to the main storefront. Automated screenshots were therefore validating the live page instead of the preview. The correct repair required understanding and changing the whole verification path. A black box could have reported success indefinitely.
This is why an execution event is recorded at the level of dispatch, retry, commitment, tool call, and memory change. “The AI failed” is not sufficiently actionable. A withdrawn memory also leaves a tombstone and warns the agent for 30 days, because a database deletion cannot remove an old belief from an active conversation.
Ownership lets safety live in code
The strongest example is a missing type: the scheduler accepts collection, analysis, and inspection jobs, but deliberately has no production-write job type. A write cannot be scheduled because it cannot be represented, and a standing test enforces that constraint.
Other executable safeguards include:
- A preview plus 1440×900 and 390×844 screenshots before any storefront release.
- Explicit human approval before live publication.
- Idempotency, a pre-write snapshot, rollback, audit, and dead-letter handling for every production write.
- A hard separation between remembered facts and actual permissions.
- Published capability states—stable, limited, unsupported, or roadmap—rather than silent approximation.
For example, Google SSO browser automation is limited because bot detection may block it, while WeChat-family and device-fingerprint-dependent apps are unsupported today. The current boundaries are on the capability page.
Why not assemble the platform from open source?
That path is valid. Creating an agent that can use tools is now relatively quick. The longer project begins afterward:
- tenant isolation, provisioning, upgrades, health reporting, backup, and rollback;
- managed and revocable credentials;
- memory divided by employee, role, and platform, including auditable corrections;
- deep collaboration objects beyond chat transport;
- seat, token, and cost accounting;
- end-to-end audit, approval gates, and recovery.
Those are engineering systems rather than model features. Once solved, they can be reused across companies. Productizing that reusable layer is why Artux exists.
FAQ
Is Artux a wrapper around an open-source agent?
No. The multi-agent runtime, cloud control plane, and training system are in-house. Similarities such as messaging, tools, and memory are category-level patterns; the differentiators are tenant isolation, managed credentials, memory ownership, and executable safeguards.
If the foundation model is external, is the platform still independently controlled?
Within a precise boundary, yes. Models supply reasoning capability; the engineering layer controls data location, authorization, audit, failure handling, and safety. Artux supports multiple credential supply modes to avoid dependence on a single access channel, but does not claim to own the model.
Did twelve months of in-house work make the product slower to improve?
Connecting an agent was not the goal. The work was the path from a demonstration to a service a company can operate continuously. Customers receive the operating controls at the end of that path rather than starting the same infrastructure project.
How can the claims be verified?
Use the capability matrix for explicit support states and the pricing page for current commercial limits. During a trial, test one recurring production-like workflow rather than a prepared demo.
Will customers be locked in?
Artux is a hosted product and does not claim to be customer-deployed source code. The portable assets are the company's procedures, role manuals, skills, and knowledge. Business-system authority also remains in the customer's own applications and can be revoked there.