DEV Community: InterCode

Rules vs. Goals: What Changes in Your Code When Marketing Automation Becomes an Agent

InterCode — Thu, 29 Oct 2026 11:52:21 +0000

TL;DR

Marketing automation runs rules a human wrote in advance. An agent gets a goal plus guardrails and picks its own path through a perceive → reason → act → learn loop.
In production, the model is rarely what breaks. Bad upstream data, mismatches between agents, brand-voice drift, and a team that doesn't trust the tool do.
Guardrails, approval queues and audit logs aren't policy documents. They're features you have to build and test like any other.

The problem: decision trees don't scale to goals

Classic marketing automation is a decision tree someone drew before launch:

Prospect views the pricing page → wait 24 hours → send email variant A → if opened, set lead score X.

Every branch is a path a human anticipated and hard-coded. That works until the number of channels, audiences and creative variants outgrows what anyone can map by hand.

An agentic system flips the contract. You don't write the branches. You define an objective and hard boundaries (budget, compliance, brand safety), and the system decides which segment to target, which creative to assemble, how to allocate bids and when to change pacing as live signals move.

For engineers, that means the core of the system stops being a rules engine and becomes a loop plus a guardrail layer.

The loop

Most goal-driven marketing agents reduce to four stages:

Perceive. Continuously ingest behavioral signals, purchase history, inventory or catalog state, channel metrics and consent status. This is a live stream, not a nightly batch.
Reason. Evaluate those signals against the goal and the active guardrails, and decide which intervention has the highest expected value.
Act. Execute it in the right channel: launch a campaign shell, shift a bid allocation, send a personalized reply.
Learn. Capture the conversion or engagement feedback and update parameters before the next cycle.

The interesting engineering sits between reason and act: everything that decides whether the agent is allowed to do what it thinks is best.

Guardrails are features, not a slide

"We'll keep a human in the loop" sounds like a management decision. In practice it's a set of things engineers have to build. Any agent that takes public-facing actions or commits client media budget needs:

Staging queues where proposed actions wait for review
Role-based permissions that define who can approve what
One-click overrides for when a human disagrees
An immutable audit trail of every decision and action

If you're building for an agency or a platform that serves many clients, this gets bigger. A single brand's internal agent works with one brand voice, one catalog and one privacy perimeter. A platform serving dozens or hundreds of competing clients needs tone, bidding guardrails and conversion goals that adapt per client, with each client's data kept apart. That's a materially larger build, and it's why this kind of work sits closer to AdTech platform development than to a weekend prototype.

Where it actually breaks

Across production deployments and industry post-mortems, four failure modes explain most stalled projects. Notably, "the LLM misunderstood the task" isn't one of them.

1. Upstream data quietly lies

Agents make confident, mathematically sound and commercially wrong decisions when their inputs are broken. If an ad platform's conversion pixel double-counts purchases, a goal-driven agent will keep shifting budget into that broken channel until a guardrail stops it.

Data access is also what drives the estimate. In our builds, the number of external integrations consistently set the engineering effort. One reputation agent had to aggregate reviews and messages from 10 sources (Google, Yelp, TripAdvisor, UberEats, DoorDash, Instagram, Facebook, OpenTable, Talabat and Deliveroo) before it could draft a single reply. If campaign telemetry, CRM records and catalogs live in unlinked silos without stable APIs, the project starts with data plumbing.

2. Handoffs fail before models do

In a multi-agent workflow, say a research agent feeding a scoring agent feeding an outreach generator, failures rarely come from the model's comprehension. They happen in the handoffs: state management and schema mismatches between agents. Coordination, not individual intelligence, is the main engineering challenge.

3. Brand-voice drift is its own defect class

In marketing, a reply or ad variation that's factually right but slightly off-brand is treated by the client as a critical bug. Catching tone violations across 1,200 hospitality locations isn't something you solve by tweaking a prompt. It takes automated evaluation that scores every generated output against a client-specific brand rubric before release.

4. The team routes around the tool

This one isn't technical, but it kills projects. Staff who worry about being automated away, and who weren't involved in rollout, either bypass the agent or magnify its early mistakes to justify shutting it down. A gradual, phased rollout with hands-on training isn't optional.

Rollout: shadow mode first

The release pattern that holds up in production:

Shadow mode. The agent runs silently against live traffic and publishes nothing. QA scores its output, for example on brand-tone accuracy.
Parallel runs. For research-style agents, compare the agent's output with what senior analysts produce on the same inputs.
Phased rollout. Enable live actions for a first cohort of accounts or locations, monitor, then expand.

Then assign a named AgentOps owner on the client side: one person who reviews overnight execution logs, audits edge-case escalations and refines guardrail parameters. An unmonitored agent will drift as ad platform rules and client offerings change.

What this looked like in real builds

Numbers from projects delivered for marketing businesses:

Outdoor advertising booking (Billboards America). A multi-agent chatbot that automates client consultations and campaign setup. Campaign creation went from 45 to 10 minutes, lead conversion from 15–20% to 35–45%, and consultation automation from 0% to 70%.
Multi-agent customer acquisition (Street Digital). 10 weeks, about 4 FTEs. Manual prospect research dropped 73%, and outbound capacity grew 3.2x with zero new hires.
Multi-location reputation agent (Localyser). 6 weeks, 2.5 FTEs, 1,200 locations. Response time fell from 18 hours to 4 minutes.
Multi-tenant leasing agent (Respage). 14 weeks, 5 FTEs. It handles 62% of first-touch inquiries without a human.

The pattern holds: integration count and architecture, not model choice, set the timeline. Production builds took 6–14 weeks with 3–5 specialists.

When not to build one

If a single off-the-shelf tool solves an internal task and you aren't putting the capability into something you sell, buy it. Build when the agent becomes part of your marketing product and you have enough repeatable volume to pay it back.

Before any of that, make sure someone can write down the rules the agent is supposed to follow:

What counts as a qualified prospect
What cost-per-lead variance triggers a budget reallocation
Which conditions require immediate human escalation

If those rules only exist as a senior media buyer's intuition, the agent has nothing to learn from.

Wrapping up

The model is the easy part of a campaign agent. The work lives in the guardrail layer, the handoffs between agents, output evaluation and the rollout. Treat those as first-class engineering and the agent behaves. Skip them and it fails confidently.

The business side (buy vs. build, the economics for agencies, and a week-by-week delivery plan) is covered in our full write-up on agentic advertising.

How AI Agents Actually Work in Property Management: Workflows, Failure Modes, and Multi-Tenancy

InterCode — Wed, 28 Oct 2026 10:13:01 +0000

TL;DR

AI in property management has narrowed down to four jobs: leasing, maintenance triage, resident communication, and marketing/reputation.
These agents don't work in isolation. They read from and write to the property management system (PMS), such as Yardi, RealPage, or AppFolio.
Deployments usually fail for three reasons: untrained staff, outdated PMS data, and after-hours traffic without hard guardrails.
A custom build only makes sense when all three conditions hold: the agent is part of a product you sell, you need multi-tenant isolation, and your volume can pay back the engineering cost.

The problem: demand arrives after the office closes

Data from Respage, a multifamily marketing platform, shows that most prospective renters send inquiries after 5:00 PM. Their questions are usually simple: pet policy, parking, move-in fees, tour times. But a reply the next morning often comes too late, because the renter has already booked a showing at another property.

That timing gap is why AI agents in this space have moved from experiments into everyday operations. In the Yardi ecosystem, for example, operators already run agents that categorize vendor invoices, check utility charges against historical baselines, and generate lease renewal offers without a human in the loop.

Four jobs, four workflows

1. Leasing

The leasing agent works across email, SMS, web chat, and voice, and pulls from the property's live availability feed in the PMS instead of following a fixed decision tree.

Take a prospect asking whether a two-bedroom allows a large dog and whether there's a tour slot on Saturday. The agent:

checks the lease rules for that specific unit
confirms open slots in the live calendar
answers the policy question
pre-qualifies the prospect against income and credit thresholds
books the tour in the leasing calendar
sends follow-up reminders to cut no-shows

Respage's AI leasing agent handles 62% of first-touch inquiries without a human and passes the other 38%, the complex or exception-based conversations, to leasing staff.

2. Maintenance triage

The agent sits at work order intake. It asks diagnostic questions, asks the resident for photos or short videos, and classifies severity before anyone is dispatched.

For minor issues such as a tripped breaker, a garbage disposal that needs resetting, or a dead thermostat battery, it walks the resident through a fix and avoids a billable vendor visit. When a real repair is needed, it:

creates a structured work order in the PMS
matches the fault category to the operator's approved vendors
checks contractor availability
schedules the repair window with the resident

3. Resident communication

Because these agents read the resident ledger and the lease directly, they can explain things like a prorated water charge or move-out notice rules in seconds, through the portal, SMS, or email.

On renewals, the agent tracks upcoming lease expirations, generates offers from approved rent matrices, sends follow-ups in sequence, and routes signed addenda back into the PMS.

4. Marketing and reputation

Generative agents write listing descriptions for individual floor plans and push updates to syndication portals whenever vacancy changes. In larger operations, multi-agent systems also handle outbound prospect research and campaigns.

Reputation agents monitor reviews on Google, Apartments.com, and Yelp across hundreds or thousands of locations, draft responses within minutes, and flag recurring complaints for regional managers.

In all four cases, the agent is only as useful as its connection to the systems it reads from and writes to. That makes most of this work an exercise in AI integration with existing business systems, not just model choice.

Three failure modes

1. Staff don't understand or trust the agent

A one-hour walkthrough at launch isn't enough. Each role works with the agent differently, and each breaks it differently when untrained:

Leasing consultants override the calendar, double-book units, or send duplicate emails.
Accounts payable re-audits every invoice the agent categorized, which wipes out the time savings.
Maintenance supervisors don't adjust dispatch rules, so technicians ignore the AI's troubleshooting notes.
Residents never hear about the new channel and keep calling the office.

The result is shadow spreadsheets and manual workarounds. Training has to be role-specific and continuous. Baseline metrics should be set before launch and reviewed after the first month.

2. The PMS data is outdated

The agent sits downstream of the system of record. If unit availability, concessions, pet weight limits, or vendor lists are outdated, or scattered across disconnected spreadsheets, the agent will give answers that are fluent, confident, and wrong. PMS data cleanup has to happen before the agent goes live.

3. After-hours runs without supervision

The evening window is where an agent wins tours that would otherwise be lost. It's also when no manager is watching. That's when an agent can misread a fair-housing question, quote a rent concession that has expired, or fail to escalate an emergency water leak.

The article this is based on is explicit: hard guardrails, deterministic fallback rules, and strict escalation triggers must be in place before the agent handles evening traffic.

What a platform needs that a single operator doesn't

Most off-the-shelf tools are designed for one operator running its own portfolio. A proptech platform, franchise network, or management group serving many independent companies needs a different architecture:

behavioral rules defined per client
escalation paths specific to each management company
brand voice guardrails per property owner
logical or cryptographic data isolation per client
multi-tenant admin APIs
token metering at the tenant level
granular permission layers

Tools sold to individual operators rarely expose these. This gap is the main technical reason platforms choose to build.

What delivered builds looked like

Project	Scope	Team	Timeline	Cost	Outcome
Respage	Commercial AI leasing agent	2 AI engineers, 1 full-stack developer, 1 MLOps engineer, 1 PM	14 weeks	$140K–275K	62% of first-touch inquiries handled without a human
Street Digital	Multi-agent customer acquisition	2 AI developers, 1 backend engineer, 0.5 PM, 0.5 QA	10 weeks	$115K	Manual prospect research −73%; outbound capacity 3.2x with no new hires; $320K+ new pipeline in 5 months
Localyser	Reputation agent across 1,200 locations	1 AI specialist, 1 backend engineer, 0.5 QA	6 weeks	$45K	Response time from 18 hours to 4 minutes; ~1,100 triage hours deflected monthly; payback within 3 months

The Respage AI leasing agent is a good example of the first build condition: the agent is a core feature Respage sells to its own property management clients, not an internal tool.

Localyser shows the volume condition. It paid back in three months because the savings came from 1,200 locations. The same build across 20 locations wouldn't recover its cost.

Build or buy

Vendors spread the cost of research, voice-model tuning, and PMS maintenance across thousands of buildings. An operator with 200–500 units won't beat that by funding its own leasing chatbot.

Build only when all three conditions hold:

The agent is part of a commercial product you sell to customers.
You need multi-tenancy with per-client rules and data isolation.
Your volume is high enough to amortize the engineering investment.

Don't build if an existing tool already covers your needs, if your portfolio is under a few hundred units, or if you can't name the metric the system has to move.

For most operators, the practical path is to buy and invest in training:

EliseAI for full-cycle multifamily leasing
AppFolio Realm-X or Yardi Agents for automation inside those PMS platforms
Showdigs for scattered-site portfolios

A basic website chatbot can launch in a day. A deeply integrated leasing or maintenance agent takes several weeks to connect to the PMS and test against real vendor lists and escalation workflows.

For proptech platforms and large operators that hit the ceiling of off-the-shelf tools, the multi-tenant architecture above is where the real engineering work starts. That's the focus of proptech software development at InterCode.

The Hard Part of AI Agents for Marketing Platforms Isn’t the Model. It’s Everything Around It

InterCode — Fri, 16 Oct 2026 12:33:44 +0000

When you put AI agents inside a product that serves many marketing clients, most of the work goes into integrations, tenant isolation, and human approval, not prompts.
We structure these systems in five layers: channels → agents with guardrails → approval queue → escalation routing → per-client data store.
Results from production builds: review response time cut from 18 hours to 4 minutes across 1,200 locations (6-week build), and 62% of first-touch tenant enquiries handled without a human (14-week build).

The problem: agents that speak for someone else

An internal chatbot answers your own team's questions. An agent inside an agency or marketing platform does something riskier: it writes review replies, ad variations, and lead messages on behalf of your clients, in public.

That changes the engineering requirements:

Many tenants. Every client has its own brand voice, banned phrases, channels, and escalation rules.
Public output. A bad reply sits under a client's Google listing, not in a Slack thread.
Mixed data sources. Review sites, ad platforms, CRMs, property management systems, and inboxes, each with its own auth, limits, and quirks.

Seven agent shapes, one pattern

Across marketing products, we keep building the same seven shapes:

Agent	What it does
Response	Drafts on-brand replies, escalates sensitive ones
Qualification	Scores leads, answers first-touch questions
Research	Gathers prospect context for sales
Creative adaptation	Reshapes assets per placement
Assembly	Builds a draft campaign from a brief
Insight	Answers performance questions in plain language
Orchestration	Decides which agent runs and when a human steps in

In code, the first six are mostly the same thing: a goal, a set of tools, and a policy for when to stop and ask a person. The seventh is the coordination layer. That's where AI agent orchestration does most of its work: routing, shared state, and handoffs.

The 5 layers

Channel integrations. Review platforms, ad networks, CRMs, PMS, email, SMS.
Agent layer with guardrails. Generation plus checks for tone, banned content, and confidence.
Human approval queue. Drafts waiting for a person.
Escalation routing. Sensitive cases go to the right human, fast.
Client data store. Per-tenant context, examples, and history.

Layer 1 is usually the biggest share of the effort. Webhooks versus polling, rate limits, token refresh, and normalizing ten different "review" objects into one schema is where weeks go. If you're scoping a project, scope the API and integration work first.

Per-tenant policy

Every decision the agent makes should read from a tenant policy, never from hardcoded defaults.

// Simplified illustration of the pattern, not production code
interface TenantPolicy {
  tenantId: string;
  brandVoice: {
    tone: string;            // e.g. "warm, concise, no exclamation marks"
    bannedPhrases: string[];
    examples: string[];      // approved past replies used as few-shot context
  };
  channels: Array<"google_reviews" | "facebook" | "email" | "sms">;
  autoPublish: {
    enabled: boolean;
    minConfidence: number;   // below this, a human approves
    minSourceRating?: number; // e.g. only auto-reply to 4–5 star reviews
  };
  escalateOn: string[];      // e.g. ["legal_threat", "safety", "refund_request"]
}

The approval gate

Every draft goes through one routing function, so "publish, approve, or escalate" is a single, testable decision:

type Draft = {
  tenantId: string;
  channel: string;
  text: string;
  confidence: number;
  flags: string[];          // produced by classifiers/guardrails
  sourceRating?: number;
};

type Route = "publish" | "approve" | "escalate";

function routeDraft(draft: Draft, policy: TenantPolicy): Route {
  if (draft.flags.some((f) => policy.escalateOn.includes(f))) return "escalate";

  const { enabled, minConfidence, minSourceRating } = policy.autoPublish;
  if (!enabled) return "approve";
  if (draft.confidence < minConfidence) return "approve";
  if (minSourceRating !== undefined && (draft.sourceRating ?? 0) < minSourceRating) {
    return "approve";
  }
  return "publish";
}

Start every tenant with autoPublish.enabled = false. Turn it on per channel once the approval data shows humans rarely edit the drafts.

Tenant isolation in retrieval

The quickest way to lose a client is to quote another client's data in their reply. Scope every read by tenant at the data layer, not in the prompt:

async function getContext(tenantId: string, query: string) {
  // The tenant filter is enforced here, never left to the model
  return vectorStore.search(query, { filter: { tenantId }, topK: 5 });
}

What this delivered

Review management, 1,200 locations. Response time went from 18 hours to 4 minutes. It was a 6-week build with a team of about two and a half people, and it paid for itself within 3 months. This ran on top of the reputation management platform we had modernized.
Leasing assistant for apartment marketing. It handles 62% of first-touch tenant enquiries without a human. It was a 14-week build with a team of five, multi-tenant, and integrated with property management systems.
Acquisition engine for a multifamily marketing agency. It cut manual prospect research by 73% and raised outbound capacity 3.2x without new sales hires.

Trade-offs and gotchas

Integrations dominate the estimate. Count channels before you count agents.
Brand voice fidelity has a cost. You need per-tenant examples and an evaluation set for each voice, not one global prompt.
Volume decides payback. The review project worked because it replaced about 1,100 hours of monthly admin triage. Low-volume workflows may never pay back a custom build.
Don't automate an unstable workflow. If the manual process changes every month, fix it first.
Decide on data and IP ownership up front. That covers prompts, evaluation sets, logs, and any fine-tuning data.
Pick the metric before the model. Response time, enquiries handled, research hours saved. Without one, you can't tell if it works.

How the delivery usually runs

These projects take 6–14 weeks:

Discovery and feasibility
Architecture and data access
Build with guardrails
Validation and production

Wrapping up

The model is the easy part. What makes these agents safe to ship is the plumbing around them: integrations, per-tenant policy, an approval gate, escalation, and strict data isolation.

This article was drafted with AI assistance and reviewed by the InterCode team.

Jev AI by TypeSafe: What a Decision Model Does Better Than an LLM, and What It Can't

InterCode — Fri, 09 Oct 2026 15:10:27 +0000

Most "AI" calls in production aren't conversations. They're decisions: which queue should this ticket go to, is this action safe, how urgent is this lead. We still send them to generative LLMs and then parse JSON that sometimes arrives with a chatty preamble or an invented field.
Jev, released by TypeSafe AI on September 15, 2026, takes a different route: it can't write text at all. It reads a state and a schema, and returns typed answers with calibrated probabilities in 70 to 500 ms. Here is how it works, where it saves money, and where it breaks.

Why decisions don't need generation

Even with constrained decoding, an LLM builds a structured answer one token at a time. A 60-token JSON routing decision means 60 sequential passes through the model. And the logprobs it exposes describe how likely the next token is, not how likely the decision is to be correct.
Jev is a prefill-only model. The whole request goes through the transformer once, and specialized heads score the options in parallel. It is trained on synthetic data with a method TypeSafe calls RLCD, which penalizes miscalibrated probabilities instead of rewarding answers that humans like. As a result, asking ten questions about the same state costs barely more than asking one.

Three primitives

• Choice: pick one label from a set. Returns the winner, the full probability map and a confidence value.
• Score: place something on an ordered rubric, such as severity or frustration. Returns a score, probabilities and confidence.
• Noul: check whether a statement is true. Returns one probability between 0 and 1, with no separate confidence, because the probability is the certainty.

Pricing is $0.042 per million input tokens, and output tokens are free.

Is it really 40-400x cheaper?

TypeSafe markets that range, so let's test it. Take 1 million classifications a month, at about 400 input and 50 output tokens each. Jev costs roughly $16.80. A mini-class LLM costs about $90, and a frontier model about $1,950.
That's 116x cheaper than a frontier model but only 5.4x cheaper than a small one. Most teams already route high-volume, low-context tasks to small models, so the realistic saving is closer to the second number. Note also that TypeSafe's speed claims come from internal benchmarks it admits may be biased.

Where it fits

• Routing before an agent runs. Send docs questions to search, numeric ones to SQL and creative ones to an LLM in under 150 ms. This keeps expensive models out of the loop and is a natural building block for AI agent orchestration.

• Safety gates. Ask Noul whether a proposed command could drop data or leak credentials, and block it above a threshold like 0.15.

• Output guardrails. Check generated text for PII, secrets and tone without a second LLM as judge.

• Ticket triage. Department, frustration level and executive urgency come from one call.

• Lead scoring. Score company size, buyer authority and urgency separately, then combine them in code with coefficients. Business priorities change without prompt rewrites, which makes this a good fit for AI automation workflows.

• RAG filtering and reranking. Screen 20 retrieved chunks in parallel. On TypeSafe's own legal retrieval benchmark, reranking lifted top-1 precision from 5% to 18% and top-10 from 38% to 62%.

Where it breaks

TypeSafe documents 9 failure modes. The ones that matter most:

• Literal reading. Unstated implications are invisible, so spell out edge cases in the criteria.

• No arithmetic, counting or date logic. Do the math in code. To count, ask a yes/no question per item and tally in software.

• Multi-hop relations. Flatten nested permissions or relationships in code before sending them.

• Diluted context. A huge state full of irrelevant prose degrades decisions, so send only the relevant chunks.

• Prompt injection. Malicious text inside the state can override your instructions, so sanitize inputs.

• Option order. Probabilities can shift when you reorder choices. Sort options deterministically.

• No generation. If you need an explanation, use an LLM.

The pattern that works: deterministic prep in code, the decision model in the middle, and confidence thresholds on top. For example, execute at 0.85 or higher, fall back to a generative model between 0.50 and 0.85, and send anything lower to human review.

Alternatives that appeared within weeks

• Cloudflare Clef and Clef-flash (Oct 1): open weights under Apache 2.0, the same API shape as Jev, plus support for up to four images. Clef-flash reports a median of about 39 ms on Workers AI. Its benchmark wins over Jev are self-reported.

• Convai Laya (around Sept 22): open source, about 421M parameters, runs locally in roughly 1 GB of RAM without a GPU, with 9-33 ms latency.

• OpenAI Decisions API (announced Sept 29): no public docs or pricing as of early October. One independent test reported 403 errors on standard keys and about 1.46 s median when simulated with structured outputs, versus the 150 ms OpenAI claims.

Critics point out that classifiers like DeBERTa and SetFit already existed, and for stable, high-volume tasks with fixed labels a fine-tuned small encoder is still cheaper and more accurate. What's new is a zero-shot, typed, calibrated API with no training pipeline.

Takeaway

For classification, routing, scoring and policy checks at volume, a decision model can cut latency and spend. Keep an LLM for anything that needs text, multi-step reasoning or explanations. The real engineering work is the wiring around it: confidence gates, fallbacks and deterministic preprocessing. That's where solid AI integration into your existing stack pays off.

Real Costs of Building & Scaling AI Systems in 2026

InterCode — Mon, 05 Oct 2026 11:59:35 +0000

Building custom artificial intelligence costs between $5,000 for a rapid proof of concept (PoC) and upwards of $500,000 for enterprise automation platforms. For standard mid-tier commercial deployments, most projects land squarely between $40,000 and $150,000.

However, software budgets often break apart when technical leaders treat machine learning like standard web app development. Traditional web apps have deterministic logic, while AI systems run on probabilistic outputs. Accurate AI development cost estimation requires budgeting heavily for testing, tuning, and ongoing token consumption.

Here is an engineering breakdown of where the budget actually goes when building AI systems in 2026.

Where the Engineering Budget Actually Goes

Data Preparation (30% to 50% of the Budget) Models do not fix messy corporate data. If your training inputs sit scattered across disjointed CSV files, legacy SQL tables, and messy PDF exports, data cleansing will consume up to half of your initial budget.

Structured Exports: Basic preparation requires roughly $6,000.

Unstructured Ingestion: Parsing medical or legal documents frequently burns $35,000 to $70,000 just to clean and index raw documents before software development even begins.

*API Wiring & Custom Middleware * An isolated AI system is rarely useful; production value comes from connecting models to transactional databases, payment gateways, and ERPs.

Basic Webhooks: $3,000 to $8,000.

Bi-Directional High-Concurrency Wiring: Implementing role-based access control (RBAC), fallback retries, and strict rate-limiting costs $18,000 to $45,000.

Legacy Middleware Adapters: Adding custom adapters for older REST APIs adds $12,000 to $25,000.

Model Selection: Fine-Tuning vs. Commercial APIs Commercial APIs: Calling closed-source foundational models through structured prompts costs as little as $1,500 to $4,000 in early setup fees.

Fine-Tuning Open Weights: Fine-tuning models like Llama or Mistral on proprietary text requires specialized data curation and compute clusters. Expect initial training runs to consume $10,000 to $45,000 before reaching target accuracy. Most teams evaluating this trade-off benefit from an outside custom AI development review before committing — the decision shapes every other line item downstream.

Cost Breakdown by Architecture Type

Proof of Concept (PoC) — $5,000 to $25,000: Bypasses scalable backend infrastructure; focuses purely on data validation, test scripts, and prompt tuning.

AI Chatbot (RAG) — $15,000 to $60,000: Requires document search pipelines, standard cloud search indices, and API integrations (e.g., Zendesk, Notion).

Agentic System — $30,000 to $180,000: Involves building tool connections, orchestration logic, short and long-term memory layers, and automated evaluation frameworks.

Custom AI Assistant — $40,000 to $150,000: Demands rich custom web interfaces, browser extensions, real-time streaming responses, and tight role-based access control (RBAC).

Custom ML Data Model — $80,000 to $350,000: Built on XGBoost/LightGBM pipelines, requiring tabular feature engineering, automated retraining triggers, and drift detection.

Enterprise AI Platform — $300,000 to $1,500,000+: Multi-tenant infrastructure built for thousands of concurrent users, with zero-trust security postures, automated PII redaction, complete audit logging, and compliance coverage (SOC 2, HIPAA, GDPR) across multiple staging environments.

The PoC-to-Production False Economy

One of the biggest pitfalls in AI development is assuming that moving from a 3-week prototype to production will take just another couple of weeks and cost $10,000.

This assumption is dangerously wrong. The prototype represents roughly 15% of the total engineering effort. Hardening the application requires building:

Latency fallbacks

Input validation

Role security

Telemetry logging

Load balancing

Failure retries

Turning a $15,000 prototype into a production-ready application requires an extra $50,000 to $90,000 in foundational engineering. Furthermore, if inexperienced teams skip MLOps (automated evaluation pipelines, latency monitoring) to save $10,000 early on, they often face $15,000 to $30,000 in emergency technical refactoring when response quality degrades post-launch.

Post-Launch Operating Expenses (OpEx)

Total post-launch AI implementation cost encompasses much more than code deployment.

Inference & Per-Token Billing: A customer service assistant handling 40,000 conversations a month can consume roughly 100 million tokens, translating to $300 to $1,500 every month just in raw vendor API invoices.

Dedicated GPU Hosting: Hosting open-source models on cloud GPUs (NVIDIA A100/H100) costs up to $1,800 to $3,200 per server monthly.

Vector Database Hosting: Large enterprise installations indexing tens of millions of records run between $1,200 and $4,500 every month in cloud infrastructure fees alone.

Continuous Retraining: Setting up automated pipelines to ingest new data and validate distribution shifts costs $12,000 to $30,000 initially, followed by $1,000 to $3,000 monthly in compute and operational supervision.

How AI-Assisted Engineering Cuts Build Costs

Modern technical delivery teams use AI coding assistants to dramatically lower final invoices. Based on verified delivery logs:

Routine CRUD and Middleware Wiring: Reduced from roughly 120 billable hours down to 45 hours, cutting development costs for that phase by 62%.

Synthetic Test Data Generation: Gathering and sanitizing edge-case records dropped from two full weeks to just two days using customized prompt scripts.

Test Suite Authoring: Automated tools draft comprehensive test suites in 20 hours instead of 60 to 80 hours.

By incorporating modern coding tools directly into the lifecycle, total hours on a mid-tier project drop from roughly 700 to 450 hours, shortening delivery cycles by 4 to 6 weeks.

What Building with Claude Actually Looks Like in Practice

InterCode — Thu, 24 Sep 2026 12:30:34 +0000

There's a lot of talk right now about "AI-powered development." Most of it stays vague.

A demo here. A chatbot widget there. A blog post about "the future of coding."

We wanted to write something more concrete instead: what it actually looks like to build a production system with Claude, end to end, for a real paying client.

At InterCode, we're an AI development studio. Our team is made up of CCAR-F Claude Certified Architects by Anthropic.

That means Claude isn't a side experiment for us. It's part of how we architect systems from day one.

In practice, that usually means Claude shows up at more than one layer of a project. Not just as a chatbot bolted onto a finished product afterward.

It's part of how the system gets built. Part of how it makes decisions once it's live. Sometimes even part of how it looks.

We've done this enough times now to have a pretty clear picture of where each layer actually earns its place. Here's a breakdown of one project where all three show up.

Where Claude fits into the stack

We don't bolt on "an AI feature" as an afterthought. On this project, Claude runs through three distinct layers:

1. Claude Code — for building the thing itself Our engineering team used Claude Code throughout development: designing the microservice architecture, working through the data pipeline design, and writing backend and frontend code. This is the layer most engineers reading this will recognize - an AI pair-programmer embedded in the actual dev workflow, not just an autocomplete suggestion.

2. Claude API — for the product's own intelligence This is where it gets more interesting. The Claude API powers several in-product features that the client's marketing team now relies on daily:

Turning property specials into optimized ad copy automatically
Classifying and excluding negative keywords, using property-level context instead of generic keyword lists
Ingesting emailed reports and alerts to surface anomalies and recommended actions - without a human reading every report line by line
Powering an internal natural-language chatbot so the marketing team can just ask the data questions instead of building a new dashboard filter every time

**3. Claude for the UI/UX design work **Even the design side of the platform leaned on Claude — from early UI exploration to refining the actual dashboard experience users interact with daily.

The point isn't "we used AI everywhere for the sake of it." Each layer solves a specific, boring, expensive problem: writing ad copy by hand doesn't scale, reviewing keyword lists by hand doesn't scale, reading every alert email by hand doesn't scale. Claude removes the manual step at each of those points, with engineers still supervising the output.

This particular project is a BI and marketing-automation platform we built for Street Digital, a digital marketing agency serving luxury apartment communities — replacing a no-code setup that worked fine early on but couldn't keep up once their client base grew.

Why this matters beyond one case study

Most companies don't need "an AI feature" bolted onto an existing product.

What they actually need is someone to look at the real bottlenecks. The manual ad copy. The manual keyword review. The manual report reading.

Then figure out which of those a properly supervised AI agent can take off someone's plate entirely — and which ones still need a human in the loop.

That part is genuinely hard to get right.

It's where having architects who understand both the engineering side and Claude's actual capabilities makes the difference. Not treating Claude as a black-box API call. Treating it as part of the architecture.

Why Modern Platforms Are Switching to AI Automation (And How to Do It Right)

InterCode — Thu, 24 Sep 2026 11:44:14 +0000

Technology moves fast, and staying competitive today means one simple thing: speed. Customers no longer want to wait hours or days for an email reply just to check prices or campaign options. At the same time, forcing your sales and support teams to spend hours on repetitive, manual tasks is expensive and hard to scale.

At InterCode, we regularly see how moving toward smart AI automation helps businesses take over repetitive tasks and free up human teams for strategic growth.

Here is why AI automation matters, how it saves hours of work, and how it operates in practice.

1. Freeing Teams from Monotonous Routine

The biggest value of AI isn't just about using new tech - it is about removing everyday bottlenecks.

In traditional setups, sales reps often spend nearly an hour on a single call just guiding a client through basic catalog options and schedules. Doing this manually for every customer makes scaling impossible. To make matters worse, any client browsing your site after work hours usually leaves without an answer because no one is online to help.

Smart AI agents fix this effortlessly:

Instant self-service: Visitors get immediate answers 24/7, turning casual traffic into active leads while your team sleeps.
Massive time savings: Routine tasks that used to take 45 minutes are wrapped up in under 10, letting your sales team focus on closing big deals instead of answering basic questions.

2. Beyond Simple Bots: How Multi-Agent Systems Work

Standard chatbots usually break down during longer conversations - they lose context, give generic replies, or make things up.

Modern AI works differently. Instead of one single bot, it relies on a team of specialized AI agents that work together in the background while keeping full track of the conversation:

Dispatcher Agent: Greets users, captures their contact details on the spot, and saves them to your database.
Knowledge Provider Agent: Connects directly to your internal knowledge base to give accurate, up-to-date answers about products, inventory, and pricing.
Smart Guardrails: Filters out irrelevant topics to keep the conversation strictly professional and focused.

For example, when we built our AI Booking Multi-Agent Chatbot for the advertising industry, this multi-agent structure allowed the platform to handle complex billboard searches and booking inquiries automatically without losing data along the way.

3. Smooth Hand-offs to Human Teams

AI isn't here to replace your team — it is here to make them faster and more effective.

Automatic Lead Routing: When a complex request comes in, the system instantly generates a high-priority ticket in your CRM (such as Zoho) and alerts your team.
Ready-to-Close Context: Instead of reading through long chat histories, your sales managers get a short, clear summary of what the customer needs so they can step in immediately and close the deal.

This always-on setup helps platforms respond instantly and double their conversion rates without increasing headcount.

Key Takeaway

Adding AI agents to your business isn't about replacing people; it's about eliminating boring, repetitive tasks. When AI handles initial inquiries and data checks around the clock, your business moves faster, saves money, and scales with ease.

How We Built AI Agents to Eliminate Manual Copywriting and Ad Management at Scale

InterCode — Thu, 24 Sep 2026 11:07:18 +0000

Managing high-volume ad campaigns across multiple platforms often feels like an endless loop of repetitive tasks. Team members spend hours writing similar ad variations, manually excluding negative keywords, and digging through scattered reports to figure out why a campaign's Cost Per Lead (CPL) suddenly spiked.

When our team at InterCode took on the challenge of transforming a complex marketing platform, our goal was clear: eliminate repetitive manual workflows without sacrificing human oversight.

Here is how we designed AI-driven automation workflows that handle copywriting, negative keyword classification, and natural-language data analysis at scale.

1. Automated Ad Transformation (Goodbye, Manual Copywriting)

One of the biggest time sinks in multi-campaign management is turning special offers, product updates, or local promotions into platform-ready ad copy.

The Challenge:
Marketing teams manually wrote and adapted ad variants for each channel (Search, Social, Display) whenever a new promo launched.

The AI Solution:
We built an automated pipeline using LLM integrations that (which we implemented as part of our Street Digital Media project) that:

Ingests structured offer data directly from internal management systems.
Transforms promos into optimized ad copy tailored to the specific character limits and formatting requirements of target platforms.
Pushes approved copy directly to campaign management systems, drastically reducing launch times from hours to seconds.

2. Context-Aware Negative Keyword Classification

Broad negative keyword lists often block relevant traffic or fail to stop budget waste because they lack real-time context.

The Challenge:
Static negative keyword lists don't account for dynamic variables like changing inventory, localized pricing, or shifting service availability.

The AI Solution:
Instead of relying on rigid, pre-made keyword lists, we implemented contextual AI classification:

Real-time context checks: The system analyzes contextual parameters (e.g., current pricing, unit mix, geographic availability).
Smart exclusion: AI automatically flags and excludes negative search queries that don't match the active product state.
Budget protection: By preventing irrelevant clicks before they happen, ad spend is automatically preserved for high-intent users.

3. Conversational Data Analysis with Natural Language

Data without quick accessibility creates bottlenecks. Marketers often wait on analysts to query databases or build custom dashboards just to answer basic performance questions.

The Challenge:
Dashboards can be overwhelming, and finding specific insights (like root causes for performance drops) takes time.

The AI Solution:
We integrated an internal LLM chatbot connected to unified reporting data:

Ask in plain English: Team members can ask direct questions like "Why did CPL spike last week?" or "Which channel brought the highest return this month?"
Instant, data-backed answers: The system queries pre-processed data and returns clear, conversational explanations alongside actionable recommendations.

Need your feedback on my SaaS startup

InterCode — Thu, 06 Mar 2025 01:17:37 +0000

Guys, need your help!

I'm a founder of Startup - SaaS Starter Kit. I launched 3 months ago and my goal of posting here is to get feedback, customers and user testers. Here we go - http://startsaas.com/

It is a development boilerplate custom solution aimed to save ~$20'000 and 2.5-3 months of initial custom development of SaaS, CRM, HRM, and Project Management tool.

Functionality modules:

Authentication
Dashboard
User or Teams subscription model
Admin mode support
File storage management
Internationalization
Stripe integration
Subscription management
Responsive design
DataGrid