Technology

One platform.
Many bots. Your data, your tenancy.

CoreShift is a multi-tenant, multi-bot platform. Here's what that means in plain English, the architecture that delivers it, and the path a workflow takes from trigger to completion.

/ the picture

The 30-second version.

Your existing tools — Outlook, Twilio, your CRM, your accounting software — send notifications to CoreShift when something happens worth acting on. Our bots read those notifications, do work, write to your dedicated database, and act back through the same tools when the work is done. Every action is recorded in an append-only audit log you can review at any time.

YOUR EXISTING TOOLS Outlook / Email bid invitations arrive Twilio / SMS operator commands Your CRM contacts, opportunities Accounting / QBO invoices, payments CORESHIFT PLATFORM Gateway verifies signatures · checks for duplicates · routes BOT Bid Coordinator BOT Reception BOT AR …plus the rest of the catalog Your Tenant Database isolated schema · your data only bid_bids contacts audit_log bid_responses financials processed_msgs OUTPUTS YOU SEE Telegram alerts approvals, errors Outbound email RFPs, bid PDFs Outbound SMS vendor reminders Audit dashboard review everything inbound events actions out

CoreShift's three-layer model. Each customer gets their own tenant database; bots share the platform.

/ the layers

Three layers, three jobs.

  1. The Gateway: front door for all traffic.

    Every webhook from Outlook, Twilio, your CRM, or our internal scheduler lands at the Gateway first. It does three things before any bot sees the request: verifies the cryptographic signature to confirm it's really from Twilio (or whoever it claims to be), checks for duplicates so a retried message can't double-process, and routes the request to the right bot under the right customer's tenancy.

    This means every bot starts with the same guarantee: the request is authentic, hasn't been seen before, and belongs to a real customer. Bots don't reinvent security; the Gateway provides it.

  2. The Bots: each owns one workflow.

    A bot is a piece of software that handles one type of work end-to-end. The Bid Coordinator owns bid intake → RFP issuance → vendor chasing → financial roll-up → human approval → submission. The Reception bot owns inbound contact → classification → routing → logging. The AR bot owns invoice aging → reminders → payment matching.

    Bots have personalities — they know their own commands, their own state machine, their own escalation rules. But they don't have their own infrastructure. They share the platform's database access, audit logging, and integration adapters.

  3. The Tenant Database: your data, isolated.

    Every customer gets their own Postgres schema — a named container inside our database that holds your tables and only your tables. When a bot queries your data, the database connection is configured at the connection level to only see your schema. Other customers' data is invisible to the bot's queries by construction, not by application-layer filtering (which is where bugs happen).

    If a future bug in our code tried to ask the database for "all bids" without specifying a tenant, the database would still only return yours, because the connection is scoped to your schema. See the security model in detail →

/ walkthroughs

What happens when work arrives.

Two examples of a bot in motion — pick either, or read both. Same platform, same primitives, different domains.

/ walkthrough one

What happens when a bid lands.

How the Bid Coordinator handles a real inbound bid invitation — from arrival in your Outlook to submission to the GC.

  1. The GC sends you a bid invitation.

    An email arrives in your bid-intake mailbox (e.g. bids@yourcompany.com) with the project scope, plans attached, and a deadline. Microsoft 365 notifies us via webhook within seconds.

  2. Gateway accepts and routes it.

    Our Gateway verifies the notification came from Microsoft, dedups against past notifications, then routes to the Bid Coordinator under your tenancy. Latency under 200ms.

  3. The bot reads the email and classifies the scope.

    The bot reads the email body and attachments. Using rules you configure during onboarding, it splits the scope into packages: "lighting and switchgear, send to A Lighting Co and B Switchgear; basic electrical, send to C Electric and D Electric."

    It writes a record to your bid_bids table with state RFPS_ISSUED.

  4. The bot issues RFPs to your vendors.

    For each scope package, the bot sends a templated email from your domain to assigned vendors, with the relevant scope items, your project deadline, an internal-due-date 24 hours earlier, and a unique reply-token to match responses.

  5. The bot chases vendors who haven't replied.

    On the cadence you configure (defaults 24h, 48h, 72h before deadline), the bot sends gentle reminders. If a vendor hits the cutoff without responding, the bot marks them EXPIRED and pings you on Telegram.

  6. Responses come back. The bot parses them.

    When a vendor replies, the bot reads the response — PDF, Excel, or inline text — and extracts line items, totals, and caveats. Low-confidence parses route to you for review; everything else is stored as a bid_rfp_responses row tied to that RFP package.

  7. You enter labor estimates by SMS.

    The bot texts you when material quotes are in: "All vendor quotes received for project 'Yuma DC Phase 2'. Reply LABOR YDP2 electrician=120 helper=80 to enter labor hours."

  8. The bot computes the final bid.

    Materials + labor + your configured markups (sales tax, bond, contingency, overhead, profit) = your bid total. If margin falls below your floor (default 8%), the bot doesn't submit — it texts you and waits for an override.

  9. You approve. The bot submits.

    You reply APPROVE YDP2 on Telegram or SMS. The bot assembles a PDF bid package and submits to the GC 15 minutes before the deadline. Final state: SUBMITTED. Full audit trail.

/ walkthrough two

What happens when a contract arrives.

How Contract Review handles an inbound NDA — from intake mailbox to redlined response back to counterparty.

  1. An NDA lands in your legal-intake mailbox.

    An attached agreement arrives at legal@yourcompany.com from a counterparty's counsel. Microsoft 365 notifies us via webhook within seconds.

  2. Gateway accepts and routes it.

    The Gateway verifies the notification came from Microsoft, dedups against past notifications, then routes to Contract Review under your tenancy.

  3. The bot reads the contract end to end.

    The bot parses the full document, normalizes clause structure, and writes a contracts row with state READING. Document text and section map are stored alongside the original PDF in your tenant artifacts.

  4. The bot compares against your playbook.

    Using your firm's playbook — acceptable carveouts, preferred indemnity caps, term-length defaults, jurisdiction preferences — the bot walks clause by clause and tags each one as standard, tolerable, or non-standard.

  5. The bot flags non-standard terms with severity.

    Each non-standard clause is tagged LOW, MEDIUM, or HIGH severity based on your rules. Examples: a 5-year confidentiality term where you prefer 3 is LOW; an unlimited indemnity where you cap at fees is HIGH.

  6. The bot drafts redline language for the flagged sections.

    For each flagged clause, the bot drafts replacement language matching your playbook's preferred form. Draft redlines are stored as contract_redlines rows tied to the contract.

  7. Lawyer reviews the bot's findings.

    The bot sends a Telegram summary to your reviewing attorney: "NDA from Acme — 2 HIGH, 4 MEDIUM, 1 LOW. Tap to review." The lawyer opens the review view with the original alongside proposed redlines.

  8. Lawyer approves, modifies, or rejects.

    The lawyer accepts each proposed redline as-is, edits it, or rejects it. Bot never sends without explicit lawyer sign-off on every flagged section.

  9. The bot sends the redlined response back.

    Once approved, the bot assembles a marked-up Word/PDF response with redlines in tracked-changes form and emails it back to the counterparty's counsel from your domain, with a templated cover note the lawyer can edit before send.

  10. Full audit trail captured.

    Every clause comparison, every severity flag, every lawyer decision, every outbound message lives in audit_log. Final state: RESPONDED. Searchable and exportable.

What this saves you

Different workflows, same shape: the bot owns intake, routine analysis, drafting, and chase work. The human owns judgment calls — labor estimates and margin overrides for bids; clause acceptance and redline edits for contracts. You retain decision authority and offload the assembly work.

/ what changes per customer

Onboarding a new customer takes days, not months.

Because every CoreShift bot uses the same platform foundation, onboarding a new customer is a configuration exercise — not a build exercise. Here's what we change for each customer:

Per customer What it looks like Time
Tenant schema Run one provisioning script. Creates the customer's isolated Postgres schema with all tables. ~30 seconds
Integration credentials Configure their Twilio number, their Outlook mailbox, their CRM API key. Stored in their own secrets path. ~20 minutes
Bot configuration Set their thresholds, scope rules, vendor list, templates, routing. Done in a config file or eventually a dashboard. ~1-2 hours
Intake routing Configure their email or phone to forward triggers to a watched address. One-time setup. ~15 minutes
Rolodex / data import CSV import of their existing contacts (vendors, tenants, clients) into the contacts table. ~30 minutes
Dry runs Run 2-3 real workflows through the bot with you watching. Tune rules and cadences to match your judgment. ~3-5 days

From signed contract to first live workflow: typically one week. Compare to a typical custom-software engagement: 3-6 months. For the customer-facing process timeline, see how it works →

/ the longer view

How CoreShift scales.

The platform is designed in phases. We're in Phase 1 today, with one bot in production. The architecture absorbs each subsequent phase without rewrites.

Phase Scale What's added
Phase 1 (today) 1-2 customers · 1 bot live Platform foundation, Bid Coordinator. Pilot customer onboarding.
Phase 2 2-5 customers · 1-3 bots Reception bot. Managed-database migration. Per-customer Kubernetes namespaces.
Phase 2.5 5-10 customers · 3-6 bots Customer self-service dashboard. Staff admin console.
Phase 3 10-50 customers · 6-12 bots Self-service trial signup. Bot Origination Agent automates new-tenant provisioning.
Phase 4 50+ customers · full catalog Dedicated isolation for high-sensitivity bots (Compliance, Paralegal). Multi-region option.

Customers signed before each phase get grandfathered pricing and feature access as we add capabilities. We don't run "deprecation cycles" on existing customers.