What the product is and what it costs to run
ArchiBot has to pay API rates.
ArchiBot puts AI inside a repeatable lab for Archibus upgrades, diagnostics, and support. The work behind an answer is what costs money.
ArchiBot gives Archibus partners and customers a repeatable upgrade and performance lab, WebCentral help with AI in the loop, and managed environments for development, testing, UAT, and support. It runs close to the work. That's also where the bill comes from.
Start SQL Server or Oracle-backed environments for development, testing, troubleshooting, demos, UAT, or staging.
Use WebCentral versions, AXVW and config patterns, metadata, logs, upgrade blockers, and customer-specific constraints.
Run dedicated environments, backups, monitoring, usage reporting, provider controls, and workspace operations for larger customers.
ArchiBot is a repeatable upgrade and performance lab with AI-assisted WebCentral expertise attached.
A partner recently asked for the plain explanation. That pushed the wording back toward the job instead of labels like "AI for facilities management" or "ChatGPT for Archibus." ArchiBot handles upgrade readiness, repeatable test environments, diagnostics, performance investigation, support triage, and the managed DevOps around that work.
The cost becomes clearer once you look at a serious support session. It can involve WebCentral version details, database engine and version, the Tomcat/JDK/Gradle stack, integrations, customizations, representative logs, backup format, license constraints, workspace runtime, and a human who still owns the answer. That's much more than one prompt in an empty chat window.
const archibotRun = {
workspace: ["WebCentral", "SQL Server or Oracle", "Tomcat/JDK", "backup restore"],
context: ["AXVW", "config", "metadata", "logs", "customizations", "known pain points"],
aiLoop: ["search", "inspect", "reason", "tool calls", "triage", "human review"],
costDrivers: ["long context", "frontier retries", "provider API rates", "environment runtime"]
};API products pay the meter.
I wrote about the broader move from flat subscriptions to usage billing in The Token Free Lunch Is Ending. ArchiBot has a narrower problem. It pays provider rates for model calls and carries the workspace, storage, checks, and human review around them.
Provider rate cards change. That means routing, caching, and scoped runs have to be part of the product instead of promises added after the bill arrives. I can make the support path more efficient. I can't sell unlimited expert work as if the providers and runtime agreed to sponsor the customer.
The subsidy was a customer-acquisition tactic. The invoice was always there.
Useful answers need more context.
Generic chat stays cheap when the answer is short and the context is shallow. Upgrade and performance work needs version, runtime, database, customization, log, and backup evidence. Carrying enough of that context to avoid generic advice is the expensive part.
Docs, version notes, known config paths, metadata, and product explanations.
Repo state, AXVW/config files, logs, database shape, and environment evidence.
Tool calls, retries, test output, reasoning, summaries, and human review.
Compute, storage, backup, monitoring, provider controls, and support operations.
A fit check isn't sales theater. A short discovery step tells us whether the work matches, which data path is allowed, and what environment it needs. It also tells us whether AI usage should be included, capped, metered, or discussed as a dedicated, customer-controlled deployment.
What we need before calling the work scoped.
The first useful answer depends on the environment. A demo script can't supply that.
WebCentral version/build, database type/version, app server, JDK, Tomcat, Gradle.
Upgrade blockers, slow workflows, reports, integrations, customizations, logs.
Non-production access, staging system, restorable backup, SQL Server or Oracle plan.
Commercial SaaS approval, provider boundary, regulated data, customer-controlled needs.
Route the work instead of hiding the cost.
Sending every task to the most expensive model and hoping the margin works out isn't a plan. The cost should match the work. Static lookup can stay static. Smaller models can handle simpler jobs. Ambiguous work with a large blast radius may justify a frontier model. Some work can't run in hosted ArchiBot until its data path is approved.
archibot_model_policy:
cheap_path:
use_for: static lookup, navigation, first-pass summaries
mid_path:
use_for: AXVW review, config comparison, repeatable support triage
frontier_path:
use_for: upgrade blockers, multi-file debugging, performance investigations
always_show:
- provider boundary
- data approval path
- included credits
- overage behaviorWebCentral 2025.02+ has the strongest current reference support. Older versions start with an assessment. This isn't a hard cutoff. Older, heavily customized environments need more discovery, migration judgment, and review of environment-specific risk before they fit a repeatable support path.
We can support Oracle-backed environments, but they need extra planning around licensing, backup format, storage, and runtime footprint. Skipping that work can produce a demo that collapses as soon as it meets the customer's constraints.
The price has to match the work.
I won't sell ArchiBot as unlimited AI expertise. It's a repeatable Archibus delivery and support surface with AI in the workflow. Customers get upgrade assessment, test environments, support triage, and operating evidence. The price has to cover the model calls, runtime, storage, and human judgment those jobs consume.
I don't want to pretend the token bill belongs to someone else. Partners trusting ArchiBot with upgrade, performance, UAT, or support work need to know what it does, where the data goes, what's included, and what happens when the work outgrows the first scope.
ArchiBot earns its keep by making hard Archibus work repeatable without losing the context every time.