Gwen by Penguin AI - Healthcare Agentic AI Development Platform

1. Product overview A healthcare application builder. Users describe the application they want in a chat interface, and the platform generates a working full-stack app, seeded from a library of prebuilt healthcare starter applications so the agent adapts existing code rather than writing from scratch. Generated applications call a bundled healthcare API for clinical work: HCC and ICD coding, CDI, chart audit, prior authorization, claims, appeals, OCR, PII redaction, and synthetic data generation.

All model inference runs on Amazon Bedrock. There is no third-party LLM API key, and every call passes through one of two chokepoints, so model selection, fallback, and cost accounting are centrally controlled.

Key capabilities: chat-driven app generation with streaming output; a catalog of prebuilt healthcare agent applications used as build seeds; twelve healthcare service APIs; per-user cost metering with configurable spend caps; an authenticated external API for programmatic access; and a browser automation agent that drives and verifies generated applications.

2. Product at a glance The product ships as three container images that run together:

Studio frontend - Next.js on Node 22, non-root (appuser), port 3000/tcp. Command node server.js. Serves the chat UI, the app catalog, and the API routes that orchestrate builds. Generated applications build and run as child processes inside this container.

Healthcare API - FastAPI + Uvicorn on Python 3.12, non-root (appuser), port 3003/tcp. Command uvicorn main:app --host 0.0.0.0 --port 3003 --workers ${WEB_CONCURRENCY:-1}. Twelve clinical service routers.

Browser agent - Node 22 with Playwright/Chromium, port 9100/tcp. Command npx tsx src/index.ts. Drives generated applications for verification.

Health endpoints: frontend GET /api/health returns {"status":"ok"} for liveness, and GET /api/health?ready=1 performs a deep dependency check that returns HTTP 503 with a per-check breakdown when degraded. Healthcare API exposes GET /health, a per-service GET //health (for example /hcc/health, /icd/health), and GET /metrics. Browser agent exposes GET /health.

State: stateless containers. All persistent data lives in external, buyer-owned AWS services.

Orchestration: Amazon EKS. See Section 3 for why this product does not run on ECS.

3. Prerequisites Provision the following in your own AWS account:

Amazon EKS - required. See the constraints below. Amazon DocumentDB (MongoDB-compatible, TLS) - user profiles, session metadata, chat messages, the cost ledger, datasource records, and published-app records. The CA certificate ships in the image; point DOCDB_CA_FILE at it. Amazon ElastiCache for Redis - required for any multi-replica deployment. It backs distributed port allocation, session-to-pod routing, sliding-window rate limiting, and the build queue semaphore. Without it the platform falls back to in-memory stores that are wrong across replicas. Amazon EFS with a ReadWriteMany PersistentVolumeClaim - mounted at AGENT_WORKING_DIR so session state and package caches survive pod restarts. Amazon Bedrock with Claude model access enabled in the deployment Region - the inference engine. Access is granted per Region in the Bedrock console; a Region without it fails at runtime. Amazon S3 - dataset catalog and generated-application assets. AWS Secrets Manager - application secrets, surfaced to pods through the External Secrets Operator. Application Load Balancer with sticky sessions enabled and an idle timeout of at least 300 seconds. KEDA and a Prometheus endpoint if you want the shipped autoscaling behaviour. Three constraints make Amazon EKS a hard requirement, not a preference:

Session affinity. Build output streams over Server-Sent Events, and a session's generated application runs as a child process inside one specific frontend pod. Requests must return to that pod, which is why the ALB needs cookie-based sticky sessions. ReadWriteMany storage. Multiple frontend replicas mount the same working directory, which EFS provides and EBS does not. Long request duration. Build requests run up to 300 seconds, so the load balancer idle timeout must exceed that. A single-container Docker deployment is supported for evaluation (Section 4) but does not provide the affinity or shared storage a multi-user deployment needs.

4. Deployment (high level) Subscribe and pull the three images from Amazon ECR (URIs and tags on your Launch page):

aws ecr get-login-password --region us-east-1 | docker login --username AWS
--password-stdin 709825985650.dkr.ecr.us-east-1.amazonaws.com docker pull //gwen-studio: docker pull //gwen-healthcare-api: docker pull //gwen-browser-agent: Provision the prerequisites in Section 3 and enable Claude model access in Amazon Bedrock for your Region.

Create two IAM roles and bind them with IRSA. The shipped manifests use a separate ServiceAccount per workload, so each gets its own least-privilege role. The browser agent makes no AWS calls and therefore has no ServiceAccount and no role.

ServiceAccount gwen-sa in namespace penguinai-studio serves the wfb-frontend Deployment. Suggested role name: penguinai-gwen-app-data-access-irsa-role. ServiceAccount healthcare-api-sa in namespace penguinai-services serves the healthcare-api Deployment. Suggested role name: penguinai-gwen-healthcare-api-irsa-role. The wfb-agent Deployment has no serviceAccountName and needs none. Both roles need the same permission shape, scoped to the resources each workload actually uses:

bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream on the model ARNs you configure. The frontend uses the InvokeModel API and the healthcare API uses the Converse API; both are covered by these two actions. If you use cross-Region inference profiles or application inference profiles for cost attribution, allow the action on those ARNs too. s3:GetObject, s3:PutObject, and s3:ListBucket on the buckets that workload reads or writes. secretsmanager:GetSecretValue on that workload's secret, plus kms:Decrypt if it uses a customer-managed key. For each role: associate an OIDC provider with the cluster, then create the role with a trust policy allowing sts:AssumeRoleWithWebIdentity where the provider's :sub condition equals system:serviceaccount:: for that pair. Annotate the ServiceAccount with eks.amazonaws.com/role-arn=arn:aws:iam::<ACCOUNT_ID>:role/<ROLE_NAME>:

kubectl annotate sa gwen-sa -n penguinai-studio
eks.amazonaws.com/role-arn=arn:aws:iam::<ACCOUNT_ID>:role/penguinai-gwen-app-data-access-irsa-role --overwrite kubectl annotate sa healthcare-api-sa -n penguinai-services
eks.amazonaws.com/role-arn=arn:aws:iam::<ACCOUNT_ID>:role/penguinai-gwen-healthcare-api-irsa-role --overwrite <ACCOUNT_ID> is your AWS account. A single eksctl create iamserviceaccount per pair performs the OIDC association, role creation, and annotation in one command.

The shipped k8s/prod/ overlay uses a distinct pair - ServiceAccount gwen-sa-prod in namespace penguinai-studio-prod with a -prod suffixed role - so production gets its own identity rather than sharing the non-production one.

Deploy on Amazon EKS. Kubernetes manifests ship with the product covering the three Deployments, Services, the EFS PersistentVolumeClaim, the ServiceAccount, an ExternalSecret, a NetworkPolicy, PodDisruptionBudgets, KEDA ScaledObjects, and a ServiceMonitor. Apply the namespace and ServiceAccount first, then the ExternalSecret, then the workloads:

kubectl apply -f /namespace.yml # penguinai-studio kubectl apply -f /sa.yaml # gwen-sa (annotate per step 3) kubectl apply -f /external-secret.yml kubectl apply -f /configmap.yml -f /pvc.yml kubectl apply -f /services.yml kubectl apply -f /frontend-deployment.yml -f /agent-deployment.yml kubectl apply -f /healthcare-api/ # penguinai-services + healthcare-api-sa

kubectl set image deploy/wfb-frontend -n penguinai-studio wfb-frontend=<STUDIO_IMAGE> kubectl set image deploy/wfb-agent -n penguinai-studio wfb-agent=<AGENT_IMAGE> kubectl set image deploy/healthcare-api -n penguinai-services healthcare-api=<API_IMAGE> kubectl rollout status deploy/wfb-frontend -n penguinai-studio Expose only the frontend through an ALB Ingress with TLS, cookie stickiness, and a 300-second idle timeout. Configure the frontend liveness probe against /api/health and the readiness probe against /api/health?ready=1.

Docker (evaluation only). A single-host run is useful for a functional smoke test:

docker run -d -p 3003:3003 -e AWS_REGION= <HEALTHCARE_API_IMAGE> docker run -d -p 9100:9100 <BROWSER_AGENT_IMAGE> docker run -d -p 3000:3000
-e AWS_REGION=
-e MONGODB_URI= -e REDIS_URL=
-e NEXT_PUBLIC_API_URL=http://localhost:3003 
-e AGENT_SERVER_URL=http://localhost:9100 
-e API_KEY_PEPPER=<32-BYTE-HEX>
<STUDIO_IMAGE> On a plain host the AWS SDK takes credentials from the instance role or the environment. Do not run multi-user workloads this way; see the constraints in Section 3.

Verify (Section 8), then scale: KEDA scales the frontend on an active-session metric (the shipped ScaledObject uses 2 to 20 replicas), and the healthcare API scales on memory (2 to 8). Adjust both to your load.

5. Configuration (high level) Configuration is environment-variable driven. Put secrets in AWS Secrets Manager and surface them with the External Secrets Operator rather than committing them.

Studio frontend - required:

AWS_REGION - Region for Bedrock, S3, and Secrets Manager. The shipped default is us-east-1. MONGODB_URI - DocumentDB connection string. DOCDB_CA_FILE - path to the bundled DocumentDB CA inside the image. The shipped manifests set this; do not mount over that path. REDIS_URL - ElastiCache endpoint. Required for multi-replica correctness. AGENT_WORKING_DIR - the EFS mount path where session directories and caches live. AGENT_SERVER_URL - browser agent base URL, for example http://:9100. NEXT_PUBLIC_API_URL - healthcare API base URL reachable from generated applications. API_KEY_PEPPER - required in production. HMAC pepper used to hash external API keys. Generate with openssl rand -hex 32. Changing it invalidates every issued key. Studio frontend - operational limits (all have shipped defaults):

USER_COST_LIMIT_USD and COST_PERIOD_DAYS - per-user spend cap and its rolling window. MAX_SESSIONS_PER_USER, MAX_CONCURRENT_BUILDS, BUILD_QUEUE_TIMEOUT_MS - concurrency limits. Because generated applications build and run inside the frontend container, these directly bound pod CPU, memory, and disk. API_KEY_PREFIX, MAX_API_KEYS_PER_USER, API_KEY_CACHE_TTL_SECONDS - external API key behaviour. The cache TTL bounds how long a revoked key keeps working. EXTERNAL_API_RATE_LIMIT, EXTERNAL_API_RATE_WINDOW_MS, EXTERNAL_API_IP_RATE_LIMIT, EXTERNAL_API_ALLOWED_ORIGINS - external API throttling and CORS allowlist. TRUSTED_PROXY_HOPS - proxy hops between the client and the pod. Set 1 for a bare ALB and 2 for CloudFront in front of an ALB, or client-IP allowlisting is wrong. Healthcare API:

AWS_REGION - Bedrock Region. WEB_CONCURRENCY - Uvicorn worker count, default 1. Raising it above 1 splits in-process state per worker, including the job semaphore, the active-job set, and the in-memory job-store fallback. Scale with replicas rather than workers unless you have configured an external job store. Optional: Bedrock application inference profile ARNs for per-tenant cost attribution.

Ports: 3000/tcp (frontend), 3003/tcp (healthcare API), 9100/tcp (browser agent). Only the frontend needs to be reachable from the load balancer; the other two should be cluster-internal. Generated applications bind to loopback inside the frontend container on a high port range and are not directly exposed.

Volumes: one ReadWriteMany PersistentVolumeClaim backed by Amazon EFS, mounted at AGENT_WORKING_DIR. It holds session state and package caches across restarts. The frontend also writes to ephemeral container storage while building generated applications, so size the pod's ephemeral storage for concurrent builds. The healthcare API container writes only transient files.

6. Data, sensitive information and encryption Where data is stored - the containers hold no durable data:

User profiles, sessions, chat messages, the cost ledger, and published-app records go to Amazon DocumentDB (buyer-owned). Datasets and generated-application assets go to Amazon S3 (buyer-owned). Session working directories and caches go to Amazon EFS (buyer-owned). Port allocations, rate-limit counters, and queue state go to Amazon ElastiCache (ephemeral). Secrets go to AWS Secrets Manager (buyer-owned). Prompts and generated code are sent to Amazon Bedrock for inference. Bedrock does not retain prompts or completions and does not use them to train models. No inference data leaves AWS. If you process PHI, note that the clinical service APIs accept clinical documents and chart data. Treat DocumentDB, S3, and EFS as PHI stores, execute an AWS Business Associate Addendum, and follow Section 10.

Encryption:

In transit: the ALB terminates TLS; DocumentDB connections use TLS with the bundled CA; all AWS SDK calls use HTTPS. At rest: enable AWS KMS encryption on DocumentDB, S3, EFS, ElastiCache, and Secrets Manager when you provision them. 7. Credentials and rotation Rotate on your normal cadence (90 days or less):

API_KEY_PEPPER - rotating it invalidates every external API key that users have issued. Treat it as a planned migration, not routine rotation. DocumentDB and ElastiCache credentials - use managed rotation, then restart the workloads. Note that the External Secrets Operator refreshes on an interval, and an envFrom change does not restart pods on its own, so trigger a rollout after a secret changes. Amazon Bedrock, S3, EFS - no credentials to rotate; access is authorized by the IAM role and the credentials behind it are short-lived and rotated automatically. AWS access: use IRSA. Avoid long-lived access keys. The bundled DocumentDB CA is a public certificate authority bundle, not a secret.

8. Backup, recovery and health Backup / recovery:

Amazon DocumentDB (system of record): enable automated snapshots and point-in-time recovery. Amazon S3: enable versioning, and cross-Region replication if you need regional DR. Amazon EFS: enable AWS Backup. Losing it costs in-flight session directories and caches, not durable records. Secrets Manager: include your secret in the DR runbook; a restored cluster is not usable without it. For regional DR, confirm Claude model access is enabled in Amazon Bedrock in the failover Region; model access is granted per Region and does not follow a restored database.

Health monitoring:

Frontend liveness: GET /api/health returns {"status":"ok"} as soon as the process is serving. Frontend readiness: GET /api/health?ready=1 checks DocumentDB, Redis, the runtime, and storage, and returns HTTP 503 with a per-check breakdown when any dependency is down. Use this for the readiness probe - the plain liveness path passes even when every dependency is unreachable. Healthcare API: GET /health for the container, GET //health per clinical service, and GET /metrics for Prometheus. Browser agent: GET /health. Send container logs to CloudWatch Logs. Server-side logs are structured JSON and carry a request ID for tracing. Recommended alarms: pod restarts and crash-loops; replicas below desired; HTTP 5xx rate; readiness probe failures; DocumentDB CPU and connections; ElastiCache evictions; EFS burst credit depletion; Bedrock throttling and invocation errors (the InvocationThrottles and InvocationClientErrors CloudWatch metrics under AWS/Bedrock); and per-user cost-limit rejections. Verification steps:

curl -s https:///api/health # expect {"status":"ok"}

curl -s -i https:///api/health?ready=1 # expect 200 and all checks ok

kubectl exec -n penguinai-services deploy/healthcare-api -- curl -sf localhost:3003/health kubectl exec -n penguinai-services deploy/healthcare-api -- curl -sf localhost:3003/hcc/health

kubectl exec -n penguinai-studio deploy/wfb-agent -- curl -sf localhost:9100/health

aws bedrock list-foundation-models --region <AWS_REGION>
--query "modelSummaries[?contains(modelId,'anthropic')].modelId" --output text

kubectl exec -n penguinai-studio deploy/wfb-frontend -- env | grep AWS_ROLE_ARN kubectl exec -n penguinai-services deploy/healthcare-api -- env | grep AWS_ROLE_ARN

kubectl get pods -n penguinai-studio; kubectl get pods -n penguinai-services Then sign in and generate a small application end to end. That exercises Bedrock, DocumentDB, Redis, EFS, and the browser agent in one pass, which no probe does.

9. Service quotas, IAM and pricing Service quotas - request increases proactively via Service Quotas:

Amazon Bedrock per-model requests-per-minute and tokens-per-minute is the primary scaling constraint. The platform walks a model fallback chain and trips a per-model circuit breaker on repeated failures, so throttling degrades gracefully rather than failing outright, but sustained throttling shows up as slower builds. Also monitor EKS node capacity (generated applications build inside the frontend pods, so builds are CPU and disk hungry), DocumentDB instances and connections, ElastiCache nodes, and EFS throughput mode. IAM (least privilege). The role in Section 4, step 3 is the complete set. Bind it with IRSA. The node role or node group additionally needs ECR pull permissions.

Pricing - software is billed through AWS Marketplace at the listed rate. You separately pay standard AWS rates for the infrastructure: EKS compute, DocumentDB, ElastiCache, EFS, S3, the load balancer, Secrets Manager, CloudWatch, and Amazon Bedrock per-token inference. Bedrock token spend is typically the largest variable cost, which is why the platform meters per-user spend and enforces a configurable cap. Every dependency is an AWS service, so the whole deployment can be modeled in the AWS Pricing Calculator.

10. Security and compliance The frontend and healthcare API containers run as a non-root user. The browser agent currently runs as root because Playwright's bundled Chromium requires it in this image; keep it cluster-internal, apply the shipped NetworkPolicy, and do not expose it through the load balancer. Generated applications execute as child processes inside the frontend container. They are model-authored code running in your cluster. Treat the frontend pod as a code-execution sandbox: keep it in a private subnet, apply the NetworkPolicy, give it its own node group if you want hard isolation, and scope the pod's IAM role to only what the platform itself needs. Terminate TLS at the load balancer and expose only the frontend. Enable KMS encryption at rest on every data store, and use VPC endpoints for Bedrock, S3, and Secrets Manager so traffic never traverses the public internet. The frontend sets Content-Security-Policy, X-Frame-Options: DENY, HSTS, and X-Content-Type-Options: nosniff in production. Restrict EXTERNAL_API_ALLOWED_ORIGINS to your own origins, and set TRUSTED_PROXY_HOPS correctly or client-IP rate limiting can be bypassed. If you process PHI: execute an AWS Business Associate Addendum and use HIPAA-eligible services. Amazon Bedrock, DocumentDB, S3, EFS, ElastiCache, EKS, and Secrets Manager are all HIPAA-eligible. Enable Bedrock model invocation logging only if your compliance program requires an inference audit trail, and treat that destination as PHI storage.
11. Upgrades and release notes Upgrades are a rolling image replacement with no destructive migration:

Review the release notes for the target version and any new or changed configuration. Snapshot DocumentDB and confirm S3 versioning and EFS backups. Update all three Deployments to the matching tag. Keep the three images on the same version the frontend, healthcare API, and browser agent are released together. Verify with the checks in Section 8, including ?ready=1 and one end-to-end generation. Roll back by setting the previous tag; rollback is immediate since no destructive migration runs. If a release changes the default model, confirm you have been granted access to it in Amazon Bedrock for your Region before rolling out.

12. Support This product is provided by Penguin AI. For product support, questions, or issues, contact support@penguinai.co . AWS infrastructure issues are handled through AWS Support.

When reporting an issue, please include the image tags of all three containers, the deployment namespace, the output of GET /api/health?ready=1, kubectl get pods, and the request ID from the relevant structured log lines.