Samora's continuous action system

The answer in one sentence

Samora needs a persistent goal control plane that turns a user's objective into an explicit scope and authority contract, creates one or more subject runs, reacts to stored events and deadlines, asks short-lived agents for bounded decisions, and sends approved work through existing Samora services until the goal reaches a recorded resolution.

In simple terms: the persistent machine is the goal plus its recorded state. An OpenAI agent is one temporary thinker inside that machine.

Leads are one subject, not the architecture

What happens. A goal names an outcome and a resource scope. The scope may contain contacts, campaigns, conversations, agents, tools, documents, integrations, workflow executions, queues, reports, or workspace settings. Samora creates only the subject runs needed to coordinate that goal.

Why. If the runtime is built around a lead ID, it cannot naturally handle "repair failed workflows," "configure this agent," or "attach the new pricing guide and verify it." The durable model must be about work on typed Samora resources.

Start with behavior, then choose the machinery

What happens. The user states an outcome rather than drawing every edge. Samora makes its interpretation visible, starts safe work, and chooses later work only after it observes what actually happened.

Why. The unknown is larger than replies. A provider can reject a template, an integration can require a person to sign in, a document can fail to index, another user can edit an agent, or a campaign can exceed its error budget. Any of those facts can change the next move.

What Samora can already do

What happens today. Samora already lets people configure agents, attach tools and knowledge, connect provider accounts, manage contacts and conversations, communicate across five channels, route work to people, build campaigns and workflow graphs, wait for outcomes, retry failures, and inspect operational history.

Why this matters. The new system should operate these product capabilities. It should not replace them. The missing part is a single control layer that can understand an objective, select authorized Samora actions, watch results, and decide again.

In simple terms: Samora has many working controls and execution paths. It does not yet have one persistent goal-directed operator above them.

Samora-wide action surface

The agentic layer needs a governed way to operate more than contacts. The table below separates actions that exist in the current source from the new planning and continuity layer that does not.

The missing part is a control plane, not another tool

What happens now. Individual services know how to create agents, store documents, send messages, run workflow graphs, and manage conversations. No one durable record owns a free-form objective that crosses those services.

Why this blocks the desired behavior. Without a goal contract, resource scope, subject runs, event ledger, decision record, dynamic work, approval state, and completion test, a later worker cannot know why earlier actions happened or what remains.

The machine

What happens. A durable goal workflow owns the objective. It starts subject runs where independent progress is needed. Each run alternates among runnable work, blocked work, waiting, human attention, and resolved states. New events trigger a fresh bounded decision.

Why. This lets 100 contacts diverge while an agent configuration change remains one coordinated operation. Any worker can recover after a crash because ownership lives in records, not in process memory.

In simple terms: Temporal remembers when to wake. PostgreSQL remembers what is true. Agent workers think briefly. Existing services act.

The records that make the machine real

What happens. These records survive every model call and worker. Each has one job. Together they answer why work exists, what it may touch, what happened, what is pending, and whether the objective is done.

Why. A single prompt, transcript, or JSON state blob cannot safely represent authorization, product truth, retries, waits, and audit history.

What happens after a user gives Samora a goal

What happens. Samora turns the message into a goal contract, resolves exact resources and authority, creates the smallest useful run tree, then repeats context, decision, checked work, result, and waiting until resolution.

How Samora decides what to do next

What happens. A decision worker receives one versioned envelope. It compares the goal with the current subject, new events, prior results, other active work, waits, policy, available capabilities, and human instructions. It returns typed proposals, not executable prose.

Why. The component that understands a result should not automatically gain permission to mutate a resource. Keeping four stages apart gives Samora a clear audit trail and safe retries.

The decision envelope

Waiting is stored state, not an idle agent

What happens. A wait records which events can satisfy it and when to reassess if none arrive. Temporal suspends the run without holding a worker. The first relevant event or deadline causes one serialized re-evaluation.

Why. A four-hour timer cannot ignore a reply after ten minutes. A provider callback cannot be lost because a model process exited. A human approval may take days.

Agents are temporary decision workers

What happens. Any compatible worker can claim a bounded item, load its durable context, run one agent turn or one deterministic action, write the result, and release the lease. The durable goal workflow is the coordinator. It is code, not a permanent language model.

Why. Permanent model ownership traps state inside a process, makes failover hard, and wastes compute while the system waits. The work queue should own availability. Records should own memory.

How many agent types?

Start with one manager agent contract and a small set of narrow specialists. Add a specialist only when it needs different instructions, tools, output schema, risk policy, or evaluation. Do not create an agent for every database table. Use agents-as-tools for bounded research, classification, summarization, and drafting while the manager retains decision ownership. Use an SDK handoff only when another agent should own the rest of the current conversational turn.

Persistent state versus temporary execution

What happens. Samora stores every fact needed to resume or explain a goal. Workers and agent call stacks may disappear after each bounded turn.

In simple terms: if every model process stops tonight, Samora must know exactly what to do when an event arrives tomorrow.

Events turn reality into new work

What happens. An adapter authenticates and deduplicates an incoming event, stores it, correlates it to affected resources and goals, updates projections, then signals the relevant Temporal workflows. Each awakened run rebuilds context before deciding.

Concurrency rules

• Each subject run serializes its decisions so simultaneous events cannot create contradictory work.
• Different runs execute concurrently under workspace, provider, channel, model, and cost limits.
• A resource and operation conflict key prevents two goals from changing the same agent version or contacting the same person through the same channel at once.
• Human takeover, opt-out, legal blocks, and current permissions override older goals.
• Every item carries the goal revision, subject version, capability version, and policy version it was created under. A mismatch forces revalidation.
• The goal workflow aggregates summaries. It does not put every subject's raw history into one model conversation.

Humans are part of the state machine

What happens. Samora creates a durable human request with the exact question, proposed change, evidence, choices, allowed responders, expiry, and blocked work. The answer is an authenticated event.

Why. Approval cannot be a transient chat message. Configuration changes, credentials, customer promises, destructive actions, uncertainty, and ownership transfers need accountable people.

This is not a larger workflow graph

What happens. Traditional automation selects the next prewritten edge. The desired runtime decides which work should exist after reading the current goal and facts.

Technical shape, after the system model

What happens. Samora adds a goal control plane above current services. Temporal owns durable progression. PostgreSQL owns product and audit facts. A private OpenAI Agents SDK runtime performs one bounded reasoning turn. A fixed gate converts allowed proposals into durable work. Existing services execute it.

Why. Samora already has useful service APIs, durable contact workflows, timers, signals, retries, dispatch leases, provider correlation, human queues, and permission checks. Replacing those would create competing sources of truth.

Open-source and existing-system evaluation

What happens. Existing projects can supply orchestration, agent loops, UI events, or tool protocols. None supplies Samora's complete product truth, workspace policy, channels, human lifecycle, and audit model.

Why. Selecting an "agent framework" by name can hide the hard requirements: durable events, event or deadline races, exactly-once intent, cross-goal conflicts, authorization, and business completion.

What this feels like through chat

What happens. The user talks to one goal thread while a visible work tree changes below it. Samora shows what it understood, what it will touch, what is running, why it is waiting, which decision needs a person, and how the goal ended.

Why. A Codex-like experience comes from persistent goals, tools, task state, evidence, approvals, and bounded specialists. It does not require a model process to remain alive.

User
  "Prepare a renewal agent for WhatsApp and web chat. Use the new pricing guide.
   Run a test. If it passes, launch the September renewal campaign."

Samora
  stores Goal v1 and resolves the named agent, channels, document, workflow,
  campaign draft, permissions, current versions, and approval policy
  -> creates dependent runs for agent config, knowledge, test, and campaign
  -> an SDK turn proposes an instruction diff and document attachment
  -> fixed policy requires approval for customer-facing instruction change

User approves
  -> Samora rechecks versions and applies through existing agent and KBase APIs
  -> waits for knowledge indexing event or deadline
  -> runs a test conversation through the approved tool set
  -> evaluates the recorded test result
  -> asks for launch approval if policy requires it
  -> launches through the existing campaign service
  -> waits on campaign events and reports completion

User
  "Find why yesterday's campaign stalled. Retry only safe failures."

Samora
  resolves the campaign and affected workflow executions
  -> reads node events, provider results, dispatch attempts, and current state
  -> specialist agents classify failure patterns without changing anything
  -> manager proposes a recovery set with evidence and exclusions
  -> policy blocks unknown provider outcomes and destructive resets
  -> approved retry work uses existing workflow retry paths
  -> Samora waits for new results, then reports recovered and unresolved cases

User
  "Qualify these 100 contacts and hand interested people to sales."

Samora
  creates one goal and independent opportunity or contact runs
  -> each run can send, call, wait, answer, stop, or ask for a person
  -> inbound events wake only affected runs
  -> contact and channel conflict keys prevent duplicate outreach
  -> the goal aggregates results without placing 100 histories in one prompt
  -> final report separates interested, handed off, unreachable, opted out,
     failed, and unresolved outcomes

Information the user should always be able to ask for

• "What did you understand, and what are you allowed to change?"
• "What is running, waiting, blocked, or finished?"
• "Why did you choose this action, and which evidence did you use?"
• "Which rows or external systems changed?"
• "What requires my approval?"
• "Stop, revise the objective, or undo what is safely reversible."

Decision and delivery record

What happened. This cycle broadened the model from lead conversion to authorized work across Samora and produced a separate OpenAI Agents SDK technical specification. It did not implement the runtime or change product data.

Primary local evidence

• Frontend product routes: samora-fe/src/app.tsx:216-880
• Agent operations: samora-be/services/agent_service/init.go:20-48
• Tool operations: samora-be/services/tools_service/init.go:18-40
• Knowledge operations: samora-be/services/kbase_service/init.go:20-65
• Integration operations: samora-be/services/integrations_service/init.go:39-61
• Contact workflows: samora-workflows/internal/workflows/contact.go:180-840
• Inbound correlation: samora-workflows/internal/triggers/router.go:927-1093
• Workflow records: samora-be/database/schemas/workflows.sql:1-255
• Human operations: samora-be/services/human_operations_service/dispatch.go:173-767
• Realtime broker: samora-be/services/realtime_service/broker.go:21-64,122-203

Mandatory understanding quiz

Status: not accepted. Score: 0/8 pending. A passing score is 7/8.

Reply with answers numbered 1 through 8. The session stays open until the answers pass.