Designing an AI content engine that grows with the business

A founder records a voice note after a difficult project. The recording contains a useful lesson, a customer question worth answering, and perhaps a case study. A transcription model can capture the words. A writing model can turn them into a post.

The harder question is what happens to that knowledge six months later. Can the business find it, trust it, update it, and use it for someone who has only just made an enquiry?

I started thinking about this extension while building Lemtika's internal social publishing workflow. That system selects supported business insights, freezes its sources, generates Facebook and Threads content, and manages approval, scheduling, and recovery. I wrote about those boundaries in The LLM is not the autopilot.

The next problem is broader. A business may have recordings, product documents, approved emails, and customer questions scattered across several tools. It may need blog posts, website updates, social content, and months of useful follow-up. Several brands may share a founder while serving entirely different audiences.

Lemtika gives me a working foundation for evidence-based generation and durable publishing. The knowledge library and nurture architecture below are how I would extend that foundation. They are a proposed design, with a deliberately small first implementation.

Design for the differences between businesses

A workflow drawn as “video → transcript → blog → email → social” captures one possible route through the system. It leaves several decisions implicit.

A property business might begin with a founder describing a refurbishment. A software company might begin with a release note and product documentation. A consultancy might begin with a completed engagement and the questions a prospective client keeps asking. Even when the source format matches, the rules for using it can differ.

I would separate the implementation into a shared core, business configuration, and adapters.

The core owns sources, evidence, content revisions, approvals, workflow state, and delivery attempts. Business configuration defines the audience, current offers, writing examples, calls to action, and content policy. Adapters connect those concepts to a recording upload, a Drive folder, WordPress, a CRM, or a social platform.

This makes the cost of an extension easier to identify. Another brand may need configuration and evaluation. Another source may need an adapter and data mapping. A new industry may require additional review rules. Some changes will still need code; a generic configuration screen cannot remove every business difference.

Give knowledge a lifecycle

Persistent knowledge starts with knowing what kind of material the system has permission to use.

I would maintain three distinct collections. Original sources contain recordings, transcripts, documents, and business records. Verified knowledge contains facts and claims someone has confirmed for a particular use. Approved content contains finished articles and emails that can be reused or consulted as writing examples.

These collections should remain connected, but their authority differs. A transcript is evidence that a founder said something. It does not establish that a remembered financial result is accurate. An approved email may demonstrate the desired tone without becoming an independent source for every factual statement it contains.

For an important claim, I want a reference back to the relevant source passage or audio timestamp, the business it belongs to, the person who confirmed it, and any limits on its use. A case study can describe one project without authorizing a promise about every future project.

Each generation request assembles a bounded context package: the correct business profile, relevant verified facts, selected source passages, and suitable writing examples. It records their versions alongside the draft. The next run can retrieve that knowledge without someone manually attaching every document again.

A small library can start with explicit selection and metadata filters. Full-text and vector search become useful as the corpus grows. The database remains the authoritative record; the search index helps locate material within it. As I discussed in my article on grounding, retrieving a relevant passage does not guarantee the generated claim will follow it.

Knowledge also needs an exit path. An offer expires. A client withdraws permission. A founder corrects an earlier statement. The source gets a new version or a withdrawn status, affected drafts return for review, and future sends stop using the invalid material. Already published content enters a correction process. Retention rules must cover the original file, derived text, indexes, and operational copies.

Generate from a shared brief

Before writing channel-specific copy, the engine should decide whether there is a worthwhile piece of content to make.

A useful brief contains an audience, a question to answer, an editorial angle, supporting evidence, limits on the claims, and a suitable next step. Comparing the idea with the existing library may reveal that it adds little. That is a valid outcome. A new recording does not create an obligation to publish.

The blog, email, and social variants can then be written from the same brief and evidence. Each has a separate purpose. A blog can explain a topic in depth. An email can address one hesitation. A social post can introduce the lesson and invite further reading.

This avoids making each format depend on a summary of the previous AI output. The evidence stays close to generation, including qualifications that a short social caption might reasonably omit but a longer email still needs.

The model handles language and proposes editorial choices. Application code owns destination IDs, approved URLs, required disclosures, current offer values, and format validation. Review binds to the exact text, imagery, links, and audience context. An edit creates a new revision and requires approval again.

Images follow the same rules. For a real case study, I would prefer authorized photographs of the actual work. An asset library records provenance, usage rights, brand, and captions. Generated imagery can illustrate an idea when clearly identified as illustration; it should never masquerade as a completed project or a customer result.

Separate content production from nurture

Content production responds to new source material. Nurture responds to a person's progress through a relationship with the business. The two processes run on different clocks.

Consider an illustrative property investor journey. Someone who has just enquired might need an explanation of how the business works. Later, they may want a case study showing how the team handled a difficult project. Someone asking specific questions needs a response to those questions and an appropriate invitation to speak.

A recording made today might improve the case study used in that journey. It need not become an email sent to everyone today.

The approved content library therefore needs more than a title and a body. Each item should describe its audience, topic, question or objection, suitable stage, prerequisites, expiry, and call to action. Related pieces should share a topic-family identifier so a lead does not receive the same lesson repeatedly under different subject lines.

For the first implementation, I would use explicitly approved journey versions. Version one contains a small sequence of useful emails. New material produces an editorial proposal: add a missing lesson, replace a dated example, revise an existing item, or leave the sequence unchanged. Approval produces version two.

New leads can enter version two. Existing leads remain on their original version unless a deliberate migration says otherwise. That rule prevents a library update from quietly restarting a journey or repeating an email. A correction or withdrawal still blocks affected future sends across every version; preserving a journey must not preserve a known error.

Human approval covers the content and the rules for using it. A team can approve a revision for repeated use in a defined journey without manually approving every recipient. Changing its meaning, audience, or call to action requires a new decision.

Add dynamic selection when the library earns it

Once there is enough approved material, the engine can choose among eligible items at each decision point.

The order matters. First, code filters by brand, contact permissions, stage, expiry, prerequisites, sending interval, and content already delivered. Then a ranking step chooses among the remaining options. AI can help classify a new item or assess its relevance, while the application controls whether the item is allowed to be sent at all.

If there is no useful eligible content, the system can wait. Filling a schedule is a poor reason to generate an unsupported lesson.

Every choice should record the content revision, journey policy, and reason for selection. The delivery history must distinguish reserved, attempted, confirmed, and uncertain sends. A scheduled message is not evidence that the person received it.

The CRM remains authoritative for contact status and suppression. A reply, unsubscribe, booking, or change of stage may stop or redirect the next step. I would give one system ownership of sending cadence. If GoHighLevel owns the journey clock, a separate worker should not run a competing email schedule.

Keep brands separate throughout the system

A founder may run three businesses with overlapping subject matter. That makes accidental reuse more likely: a case study, an offer, or a call to action can sound plausible while belonging to the wrong company.

Each source, content revision, approval, asset, job, and destination needs an explicit brand scope. Retrieval must apply authorization before selecting passages. Storage access, cache keys, background jobs, and provider credentials must preserve the same boundary. Shared knowledge should be a deliberately approved collection.

For a small group of businesses, I would start with separate CRM sub-accounts and credentials, backed by scoped database access. PostgreSQL row-level security can help enforce database boundaries, provided the runtime role cannot bypass those policies. Database owners and privileged roles need particular care. PostgreSQL's documentation describes those exceptions.

Higher isolation requirements may justify separate databases or deployments. The choice depends on the data and operating model. Either way, “use the correct brand” in a prompt is only a writing instruction; authorization must work even when the model gets confused.

Private information needs similar treatment. Keep original recordings private, minimize sensitive details in generation context, and avoid copying them into logs or workflow payloads unnecessarily. Source text is data to interpret. It cannot authorize tool calls, change publishing destinations, or override the engine's rules.

A concrete starting architecture

I would begin with a TypeScript backend organized into modules, a worker, PostgreSQL, and private S3-compatible object storage. The architecture has several responsibilities, but it does not need a separate service for each one.

DBOS is a natural candidate for ingestion, generation, approval waits, and integration jobs because it fits the durable workflow approach already used in Lemtika. Its checkpoints and durable sleeps support work that survives process interruption. They do not make external HTTP effects exactly once. A timeout after WordPress or an email provider accepts a request still requires reconciliation before a retry. DBOS workflow documentation.

For transcription, I would evaluate Deepgram on the founder's actual recordings. Its utterance output includes timestamps and can be combined with speaker diarization. Those features make review easier, but names, addresses, amounts, and regional accents still need testing against the audio. Deepgram utterances documentation.

For generation, I would begin with one model behind an application adapter, structured outputs, versioned prompts, and a small set of reviewed examples. Model choice should follow the work it creates for the editor: unsupported claims, lost qualifications, awkward prose, repair calls, and time to approval. The evaluation should resemble the customer's material.

WordPress can remain the publishing system. Its REST API supports creating draft posts and uploading media. The adapter stores external IDs and reads back the result; SEO plugin fields and page-builder compatibility need inspection in the actual installation. An SEO draft should include an appropriate title, structure, description, and internal-link suggestions without inventing keyword research or promising rankings. WordPress posts and media.

GoHighLevel can remain the CRM and nurture delivery system. Its APIs include email template creation and contact enrollment into workflows. Those endpoints do not by themselves prove that an entire existing workflow can be rewritten safely by API. I would first configure a small journey, verify permissions and integration behavior, and exercise it with test contacts. Dynamic selection can follow once the required handoff works. HighLevel email templates and workflow enrollment.

n8n or Make can handle connectors where the customer's team benefits from managing them visually. I would keep approval records and business state in one authoritative place. Claude Code or another coding assistant can help build and maintain the system; runtime orchestration can call model APIs directly. Another CMS becomes useful only when a specific editorial need justifies it.

Make the prototype test the extension

One business, one audience, one real recording, and a small approved context pack are enough to start. The prototype should produce a transcript with source references, worthwhile content ideas, a WordPress draft with an imagery workflow, and a few email drafts if the material supports them. A test journey demonstrates how approved content is used over time.

It should also demonstrate accumulation. A later run reuses the stored knowledge. A second approved document or clearly labeled fixture proposes a library update. The reviewer can see what would change for new leads and what remains fixed for existing ones.

I would verify that a restart preserves completed work, repeated ingestion does not create duplicate logical sources, and an unapproved revision cannot enter the publishing path. Test cases should include another brand's material, a withdrawn claim, an unsubscribed contact, and an uncertain provider response. These cases exercise the promises a polished draft alone cannot demonstrate.

One recording cannot establish content quality across every topic or fill a useful six-month library. Expansion needs more source material, real editorial review, and operational observation. Begin with one brand in regular use, then add a second brand to test isolation, then additional channels and more adaptive nurture.

As volume grows, add bounded worker concurrency, per-provider rate limits, and budgets per business. Approval waits should not occupy the capacity needed for transcription or publishing. Separate heavy workloads when measurement shows they compete.

Measure the work the engine actually removes

I would track time from source to approved content, editorial correction rate, unsupported claims, cost per approved item, delivery failures, and duplicate sends. For the library, measure which audience questions are covered and which useful items are missing or stale.

Replies, bookings, and unsubscribes help assess the journeys. Attribution can connect content to observed activity; a claim of incremental growth needs a suitable comparison or experiment.

The useful expansion from Lemtika is a system that can retain knowledge, revise its understanding, and reuse approved content as the business changes. Its first deployment can stay small while making those responsibilities explicit from the beginning.

I scope and build this work through the AI Content Engine solution. The Lemtika case study covers the existing evidence-first foundation, and Services explains how an engagement runs.