Build vs. Buy — After-Call Architecture

Should PropFlow bring in an open-source project or a commercial platform for the after-call system (what happened on a call, tracking Clara's promises, getting a human involved) — or keep building it thin on Temporal? Six areas researched independently against real, current products and pricing.

2026-08-26 · commissioned by Fede · research only, no purchase made · every pricing figure below is sourced or marked "not public" — nothing invented

What "the after-call architecture" means

Three pieces, all already named in this week's own incident write-ups:

• A call-evidence resolver — one place that decides what actually happened on a call (did a transfer connect? for how long?) from the recording and Twilio's own record — waiting for the real event instead of guessing on a short clock.
• A promise ledger — tracks the commitments Clara makes out loud ("I'll text you the link") and whether they were kept, now being shrunk on purpose so fewer things need tracking at all.
• One human-notification lane — today 13 separate places in the code can page a property manager, with no check for "has someone already been told about this." The fix collapses them into one door with a dedup check, and a rule that once a human answers a question, that answer becomes standing policy and Clara never asks again.

This is measured, not guessed, from the actual codebase: the promise ledger is about 3,800 lines of code, and the human-notification ("matter") lane is about 5,800 lines — roughly 9,600 lines of homegrown infrastructure today. That size is what prompted the question this document answers.

Summary — all six areas, one screen

1. Durable execution — waiting on a real event, with a timeout

PropFlow already runs Temporal Cloud for everything durable: renewal workflows, escalations, the promise ledger. The bug that raised this question: a checker waits for a phone transfer's outcome on a fixed ~2.5-minute clock (six tries, 25 seconds apart) — but the real answer (the call recording finishing) can take much longer. On one real call it paged a property manager six minutes before a human had already, correctly, handled the caller. That's a short clock racing a real-world event with no fixed length.

Alternatives considered — and why none replace Temporal here

2. Call-outcome evidence — what actually happened on a call

The company's own principle: "we record every call, we should know this." The evidence already exists (Twilio's own call record, the recording) — the problem is reading it correctly, not acquiring more of it. One real bug found in this research: the stored outcome for one call said "connected" while Twilio's own log showed a 4-second no-answer.

One writer, not two: the ElevenLabs webhook is an input to the Call Evidence Resolver, not a second, parallel place that decides call outcome. The resolver stays the one place that turns evidence into a verdict — it just starts listening for the webhook's push instead of polling for it, and still cross-checks against Twilio's own call-leg record before deciding anything. Two writers of "what happened" is the exact failure mode section 2 opened with; this change must not recreate it under a different vendor.

3. Obligation tracking — the promise ledger's remaining scope

Fede already ruled on the direction here: shrink what counts as a "promise" that needs tracking at all — most outcomes should be stated as already-true facts backed by proof (a work order number, a confirmed tour), not tracked as an open commitment. What's left — a genuinely open human follow-up — still needs an owner, a due time, and a way to mark it done.

4. Human-notification lane — one deduped door

Today, 13 separate places in the code can page a property manager — a stuck renewal, an unanswered transfer, a maintenance approval — and none of them check whether a human has already been told about this exact issue. The plan already agreed: collapse all 13 into one "matter" per resident/issue, with a check before opening a new one, and a rule that once a human answers a question, that answer becomes standing policy and Clara never asks again. Standing company rule: never build a list of things for a property manager to work through — everything is automatic by default, and a human only ever sees one card at a time.

5. Eval / guardrail harness — catching a bad message before it sends

Direct, relevant history: PropFlow adopted Langfuse (a tracing/observability product) earlier in 2026, then removed it in July because it added more day-to-day complexity than it saved — replaced by an internal store the team fully controls. There's also a hard billing rule: Claude usage for evals must run on the team's paid subscription, never a metered API key, after a past mistake burned real money the wrong way. That rule disqualifies most of the SaaS options in this category by itself — but it's worth noting PropFlow already solved it for the one open-source tool it actually uses, well before this research pass.

None of these seven know PropFlow's own incident history or promise-detection rules — that has to be built in-house either way, which is what Cerberus already is. None of them close the voice-channel gap either: real voice testing (audio conditions, interruptions, latency) is a different, separate product category not covered by this pass. Promptfoo, the one already in production, doesn't change either of those two facts — it's a runner/config layer, not a replacement for Cerberus's domain-specific judgment.

6. Agent framework — would one make Clara's core loop simpler?

PropFlow calls Claude directly today, with hand-written code deciding which tool to use next. No name-brand "agent framework" (LangGraph, CrewAI, and similar) is in use. Company principle: Clara is one brain across leasing, maintenance, renewals, and collections — not a patchwork of separate bots — so any framework has to support one coherent agent, not encourage splitting it up.

Rough cost sketch at 10,000 units

Every figure below is a labeled estimate, not a quote — built from the sourced per-unit prices above and a rough guess at call volume (~10,000 calls/month across leasing, maintenance and renewals, ~15% involving a transfer). Nothing here should be read as a real invoice.

Directionally: in four of the six areas, buying is actually more expensive than building, because every vendor researched prices for a growing human team, not a system where one AI agent generates the volume. The two areas with a real "yes, adopt" are both free or already paid for.

Overall recommendation

The roughly 9,600 lines of in-house code that raised this question isn't, on this evidence, proof of over-building. It's the visible cost of judgment calls no vendor can make — what counts as a kept promise, what counts as "someone already knows," what really happened on a call — because all three require knowing PropFlow's own residents, leases, and call data. The bugs that triggered this whole question were mistakes inside that code, not reasons the code shouldn't exist. Fixing them is smaller, cheaper, and safer than replacing any of it with a vendor.

Decisions for Fede

Full working notes, every vendor considered, and the complete source list: see the research file alongside this page. Sources are linked inline throughout — nothing above is an invented number.