Contact us
Tech spike pre-read · MYOB R&D

How we'd integrate Lorikeet into MYOB

A tech reference covering how Lorikeet plugs into HubSpot, how we'd integrate with Acumatica's per-instance deployment, and how we handle proprietary systems. Specific where we know specifics, honest about what depends on your environment.

1 Principles

How we think about integrations

Lorikeet is the AI brain. It doesn't warehouse your data, replicate your config, or replace your systems of record. It calls into them through a tool framework: every external API becomes a callable tool the AI agent can use during a conversation, with read and write paths separated.

Three layers, three integration patterns

Ticketing

Where conversations live, get tagged, get routed, get closed. Lorikeet writes into your ticketing system as a first-class agent — read transcripts in, write replies and metadata out.

Knowledge

What grounds the agent's answers. KB articles plus scrapers against public docs plus retrieval against any internal source you expose. Source citations included by default.

Action

What the agent does on the customer's behalf — lookups, configuration changes, transactions. Each external API wrapped as a tool. Read-only first; write actions gated behind explicit confirmation steps.

We follow a deliberate sequence on every integration: read-only first, write-with-guardrails second, autonomous action last. This keeps risk low while compounding value. It's the pattern that's worked across regulated subscribers in financial services, healthcare, and payroll.

2 HubSpot integration Proven pattern

HubSpot stays the source of truth.

We have an established HubSpot integration running in production across multiple subscribers. This is not a same-day connector, but it is a known shape — we know what we need, what to ask for, and where the friction points are.

What it covers

  • Ticket lifecycle. Lorikeet creates, updates, and closes tickets via the HubSpot Engagements API.
  • Conversation transcript attachment. Full conversation log written back as structured engagement records.
  • Tagging, priority, routing. Lorikeet applies your taxonomy on resolution. Routing rules executed by HubSpot's existing workflow engine.
  • Custom property write-back. Structured metadata (topic, sub-topic, region, resolution type, urgency flag, CSAT score, summary) written to the contact and company records.
  • Read-back. Lorikeet reads recent ticket history, customer attributes, and account context to ground its responses.

What we'd need from MYOB

Portal access
Sandbox HubSpot portal during build, production portal at go-live. App-level OAuth or private app access tokens.
Property schema
List of custom properties on contact, company, deal, and ticket objects we should read and write. We can co-design new properties if useful.
Routing rules
Where escalations go, which queues, which owners, what conditions trigger reassignment.
Pipeline definitions
Ticket pipelines and stages for support, plus any deal-side pipelines we should write back to (expansion signals, churn risk flags).

What we'd need MYOB to do

  • Provision portal access during onboarding (typically a 30-min session with your HubSpot admin).
  • Confirm any data-residency or PII constraints on what gets written back to HubSpot vs. retained only in Lorikeet.
  • Decide whether escalations route through HubSpot's queues or directly to a separate human-handoff system.

Open questions for the kickoff

  • Is HubSpot already in production for Acumatica support today, or still being implemented?
  • Which HubSpot pipeline(s) handle Acumatica L1 / L2 / L3 tickets — merging with the rest of MYOB support, or kept separate?
  • Do you have an existing taxonomy and custom property schema we should write into, or are we co-designing it?
3 Acumatica integration Proven pattern

Instance-agnostic by design.

Val flagged the deployment topology as the thing past vendors have tripped on: Acumatica is single-tenanted, one EC2 instance per customer, with no inter-instance awareness. Vendors that assume multi-tenant SaaS end up "thinking they're deployed across thousands of unique sites." Our chat widget design avoids this entirely.

Why the cluster topology isn't a problem for us

The Lorikeet chat widget is an embedded iframe identified by a single public_key parameter passed to the loader. That key maps to exactly one subscriber in our database. The widget doesn't care about the origin domain, hostname, or which server instance it's running on.

  • Every instance embeds the same snippet with the same public_key. Lorikeet treats them as a single tenant — we won't see "thousands of unique sites", we see one subscriber regardless of which instance the chat was opened from.
  • End-user identity is handled separately. Either anonymous (we mint a customer ID on first message) or trusted mode where Acumatica passes a signed JWT with the customer claims. Works the same regardless of how many instances you have.
  • No origin allowlist or per-domain config to maintain. Spin up another 100 instances tomorrow, nothing changes on our end.

The only scenario you'd want multiple public keys is if you wanted separation for different brands or different reporting buckets — not because of the deployment topology.

Four integration surfaces

1 · Embed

The chat assistant in product. Iframe widget, same snippet across all instances. Sarah and Val flagged this as a high-priority capability.

2 · Context handoff

Screen ID, URL, user role, tenant ID, and any role-based context passed to the widget on initialisation or via JWT claims. Cuts the agent's "what page are you on" ask to zero.

3 · Read APIs

The agent calls Acumatica APIs to fetch configuration state, employee data, pay run status. Each wrapped as a tool. Read-only.

4 · Action APIs

L2 / L3 actions like entitlement adjustments, super reversals, employee updates. Always with confirmation gates. Always auditable.

Identity: trusted mode vs anonymous

For an authenticated app like Acumatica, we'd recommend trusted mode: Acumatica generates a JWT with the customer's claims (user ID, tenant ID, role, screen context) and passes it to the widget on init. We verify the signature against a shared secret. This gives the agent everything it needs to ground answers in the right customer's data without the customer needing to identify themselves in chat.

Anonymous mode also works and is fine for unauthenticated surfaces, but for in-product chat trusted mode is the right pattern.

What we'd need from MYOB

JWT signing key strategy
The signing secret needs to be available to all instances in the cluster. We assume your existing config / secret distribution mechanism handles this — good to confirm at the kickoff.
URL / screen-ID conventions
How screen IDs and tenant IDs are encoded in URLs, or alternatively included in the JWT claims. We consume whichever is cleanest.
API surface
OpenAPI / Swagger if it exists, or the equivalent docs. Ideally a sandbox tenant we can hit during build.
API auth pattern
How Acumatica authenticates API access, plus any per-tenant credentialling we'd need to handle for read and action APIs.
Data residency
AU only, or AU + NZ? Affects where we host inference and what data flows where.
Demo instance
Val offered access to his demo instance. We'd take that up to prototype the widget embed and JWT handoff in the spike.

Open questions for the kickoff

  • Session continuity across instances. If a customer's session bounces between instances mid-conversation, do you want the chat to persist? It will on our side — worth confirming that matches your expectation.
  • How are screen IDs and tenant IDs surfaced today — URL, JS context object, both?
  • How do customer-specific extensions (ISVs, customisation packages) affect the API contract for read and action calls?
  • What's the latency budget for an in-product chat response on the customer side?
4 Proprietary systems Depends on your stack

Snowflake, telemetry, internal services.

Val flagged that a meaningful chunk of MYOB's operational data lives outside HubSpot — Snowflake tables, telemetry, configuration databases. The honest answer: this is where finished products tend to fall over and where we tend to win. It's also where shape varies most between customers.

The general pattern

For any data source that isn't HubSpot or Acumatica, the integration shape is the same:

  1. Define what the agent needs from this source — usually a small set of read patterns, sometimes a write pattern.
  2. Wrap each pattern as a tool. The tool runs the query (Snowflake SQL, REST call, GraphQL, gRPC, whatever) and returns a scoped result to the agent.
  3. Add output transforms if the raw response is too noisy for the agent to reason over.
  4. Add auth at the tool boundary, not in the agent's prompt.

We don't replicate or warehouse. The source system stays the source of truth. If a customer's pay configuration changes in Acumatica, the next agent query reads the new state.

What we know works today

  • Snowflake. A tool that runs a parameterised query, returns a tight result set. Auth via service account or key-pair. Pattern in production at multiple subscribers.
  • Internal REST APIs. Tool wrapper, OAuth or API key. The default and most common pattern.
  • GraphQL. Single tool, query passed as input. Works well when the agent needs to compose queries dynamically.
  • Event streams (telemetry). Typically not consumed directly. Better to have a service that aggregates the signals and exposes a "get user health" or "get error context" endpoint that the agent can call.

What we'd need from MYOB

  • A list of internal services we should call into, with their docs and auth pattern.
  • Any rate limits, latency expectations, or scaling constraints.
  • A staging environment for build and a rollout plan to production.

Open questions for the kickoff

  • Which Snowflake datasets carry the configuration and telemetry context the agent should ground on?
  • Are there services we'd be expected to talk to that don't exist yet, or only exist as internal-only batch jobs?
  • Any audit / compliance requirements on what the agent can read?
5 Tech kickoff

Open questions we'll bring to the kickoff.

Consolidated list, in priority order. We'll come prepared to discuss each — answers shape the spike plan.

  1. Is HubSpot in production for Acumatica support today, or still being implemented?
  2. What blocked or made painful the previous third-party SaaS embed (Segment) inside Acumatica?
  3. What does the Acumatica API surface actually expose for read and for write? OpenAPI / Swagger?
  4. Which Snowflake datasets carry the configuration and telemetry the agent should ground on?
  5. What's the latency budget for in-product chat from the customer side?
  6. AU only for data residency, or AU + NZ?
  7. Who from R&D owns each surface — Acumatica embed, API, HubSpot, Snowflake?

Ready when you are.

Companion to this playbook: the live user journey running against your real Acumatica tickets. Happy to walk through both together.

See the user journey Book a walkthrough